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

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?  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), but unless you are trying to compile code on DOS, any system will support any length of filename that someone would bother typing into an "#include" line.