Re: Rationale for aligning data on even bytes in a Unix shell file?

On 30.04.2025 12:21, David Brown wrote:

On 30/04/2025 11:52, Janis Papanagnou wrote:

On 30.04.2025 11:06, Muttley@DastardlyHQ.org wrote:

On Wed, 30 Apr 2025 09:45:20 +0200
David Brown <david.brown@hesbynett.no> wibbled:

More relevant to this group, it make also be convenient for people
trying to work with big C code bases that were written on Windows and
you now want to compile (for whatever target you want) them on Linux.
I've seen code bases developed on Windows machines where the
capitalisation of include directives was inconsistent - that works on
case-insensitive filesystems, but not on case-sensitive systems.  (Yes,
I know there are many other ways to deal with such issues, but putting
the source code in a case-insensitive directory on ext4 is one option.)

>
I've seen on more than one occasion C++ (not C yet) projects where there
were 2 files only different in case, eg: Network.cpp and network.cpp
where
the former would be the class and the latter would be procedural
support code.
Good luck unzipping that on Windows or any other case insensitive
file system.

>
For low-level system software like network functionality that
would probably anyway not work on Windows in the first place
without change, independent of the capitalization. (But the
"case insensitive file system" issues, like the above mentioned
case inconsistencies, are of course an inherent problem.)
>
And there's of course a related problem if we port software with
longer maximum filename lengths to systems with shorter filename
lengths.
>

 
What systems are there now with filename length limits that would ever
be relevant to hand-typed names?

Frankly, I've not the least idea what all the systems around nowadays
do or don't support.

Filename length limits can
occasionally be relevant in some contexts (I've seen it in web spiders
that try to turn complete URL's into a single filenames),

Files on the Web have often pathological filename lengths. Usually I
have to rename them; because of convenience WRT length and also to
give such documents a sensible semantical name.

but unless you are trying to compile code on DOS,

Oh, I wasn't at all thinking of DOS, more on (historic) 14 character
limits on Unix systems.

Nowadays we may assume larger limits (POSIX 255 characters?). (Or in
case of 'tar' data transfers yet lower limits [for compatibility].)

any system will support any length of
filename that someone would bother typing into an "#include" line.

If there's any limits it needs to be addressed.

Janis