8 ms·

"Version" include wreaks havoc on case-insensitive filesystems

62 points by sirn 7y ago

lallysingh 7y ago
Why is the directory containing VERSION in the include path? Isn't that normally an include/, src/, or similar?
- earenndil 7y ago
  Because config.h, for whatever reason (possibly to make more easily human-editable), is created in the top-level directory.
  - CaliforniaKarl 7y ago
    It's where autoconf, when told to write out a config.h, typically puts the file. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Configuration-Headers.html#Configuration-Headers https://www.gnu.org/software/autoconf/manual/autoconf-2.69/h... for more info.
    - ncmncm 7y ago
      So, fix autoconf, if you can't retire it. It is actionably hazardous to require that a directory that contains random files be in the include path. But I'll bet it doesn't; it is probably just the lazy choice. That said, there is no requirement at all that "#include <version>" must pick up a file called "version" (of any case). The compiler could prefer a file called "version.standard-header", if it exists, or "std/version"; or, things in <> brackets could be looked up on a different list, such as one designated by "--isystem" (which does already exist). There doesn't need to be such a file at all -- the standard just says what names must be found to be defined after that point in the code. The compiler can Just Know. Or, it can recognize just Standard header names, and get them somewhere special. Which is why we don't bother about this in committee. Doing the dumb thing is dumb, no matter what we say. Do the smart thing, and trouble evaporates. I always thought it was mad that compilers shipped with standard header files that had exactly the name as appears in the standard, and that preprocessors shipped that favor or require such. If you need for the files to have exactly those names, define a cpp option naming a file with a list of them, and exactly where each is.
      - emn13 7y ago
        Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally here, and it'd be a cost to have system headers treated very differently from other headers (because it makes it harder to extend the system). So while it makes sense that system headers needn't be files - in principle - it sounds like a pretty big change too with some downsides as well. All that just for "version"?
        ncmncm 7y ago
        Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.
        a1369209993 7y ago
        > for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
        ncmncm 7y ago
        I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
        kazinator 7y ago
        I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.
darkpuma 7y ago
Case-insensitive filesystems cause so much trouble, one could almost mistakenly conclude that causing trouble is their raison d'être.
- fortran77 7y ago
  Other than Mac OSX, are there any other case-insensitive file systems in common use today? https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-insensitive-file-system-instead-of-a-case-sensitive-one https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-in... Perhaps Mac users should just apply a patch and let everyone else use case as a differentiation.
  - anticensor 7y ago
    FAT is commonly used for removable media.
    - fortran77 7y ago
      FAT is not a currently maintained filesystem that a significant base of developers, other than people interested in "retrocomputing" use.
      - redis_mlc 7y ago
        Microsoft does maintain FAT, because they license it to consumer products companies.
        ndesaulniers 7y ago
        Point is I'm not going to create a FAT partition on my disk then go work out of it.
        darkpuma 7y ago
        Maybe you won't, but other people do. Dropbox and similar services have eaten away at the practice, but a lot of people still walk around with flash drives, partition table untouched since they bought it, with all their personal and work files. Not merely just using it to transfer large photographs or pirated movies, but keeping their de facto 'home directory' in that flashdrive. For a few years in the mid to late 00s, it seemed like almost everybody was doing this. Before that, I knew people who did it with zip drives. And I even once knew a guy who tried it with DVD-RAM, but gave up pretty quick.
kazinator 7y ago
If include <version> in angle brackets finds some Autoconf VERSION detritus, it's because the compiler has been wrongly told to look for <...> headers locally. (Probably by the same Autoconf junk.) There is a (not so) modern (any more) gcc option -iquote to specify a directory to search for #include "..." without affecting #include <...>. In the TXR project I have a "signal.h" local file: http://www.kylheku.com/cgit/txr/tree/signal.h http://www.kylheku.com/cgit/txr/tree/signal.h Yet, <signal.h> is also included. Like in this file: http://www.kylheku.com/cgit/txr/tree/signal.c http://www.kylheku.com/cgit/txr/tree/signal.c which has both #include <signal.h> and #include "signal.h". This is fine, if you know what you're doing. #include <signal.h> has no business finding that local file, and will not do so, unless someone screws up.

62 points by sirn 7y ago

lallysingh 7y ago

Why is the directory containing VERSION in the include path? Isn't that normally an include/, src/, or similar?

earenndil 7y ago
Because config.h, for whatever reason (possibly to make more easily human-editable), is created in the top-level directory.
- CaliforniaKarl 7y ago
  It's where autoconf, when told to write out a config.h, typically puts the file. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Configuration-Headers.html#Configuration-Headers https://www.gnu.org/software/autoconf/manual/autoconf-2.69/h... for more info.
  - ncmncm 7y ago
    So, fix autoconf, if you can't retire it. It is actionably hazardous to require that a directory that contains random files be in the include path. But I'll bet it doesn't; it is probably just the lazy choice. That said, there is no requirement at all that "#include <version>" must pick up a file called "version" (of any case). The compiler could prefer a file called "version.standard-header", if it exists, or "std/version"; or, things in <> brackets could be looked up on a different list, such as one designated by "--isystem" (which does already exist). There doesn't need to be such a file at all -- the standard just says what names must be found to be defined after that point in the code. The compiler can Just Know. Or, it can recognize just Standard header names, and get them somewhere special. Which is why we don't bother about this in committee. Doing the dumb thing is dumb, no matter what we say. Do the smart thing, and trouble evaporates. I always thought it was mad that compilers shipped with standard header files that had exactly the name as appears in the standard, and that preprocessors shipped that favor or require such. If you need for the files to have exactly those names, define a cpp option naming a file with a list of them, and exactly where each is.
    - emn13 7y ago
      Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally here, and it'd be a cost to have system headers treated very differently from other headers (because it makes it harder to extend the system). So while it makes sense that system headers needn't be files - in principle - it sounds like a pretty big change too with some downsides as well. All that just for "version"?
      - ncmncm 7y ago
        Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.
        a1369209993 7y ago
        > for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
        ncmncm 7y ago
        I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
        kazinator 7y ago
        I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.

darkpuma 7y ago

Case-insensitive filesystems cause so much trouble, one could almost mistakenly conclude that causing trouble is their raison d'être.

fortran77 7y ago
Other than Mac OSX, are there any other case-insensitive file systems in common use today? https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-insensitive-file-system-instead-of-a-case-sensitive-one https://www.quora.com/Why-does-OS-X-choose-to-have-a-case-in... Perhaps Mac users should just apply a patch and let everyone else use case as a differentiation.
- anticensor 7y ago
  FAT is commonly used for removable media.
  - fortran77 7y ago
    FAT is not a currently maintained filesystem that a significant base of developers, other than people interested in "retrocomputing" use.
    - redis_mlc 7y ago
      Microsoft does maintain FAT, because they license it to consumer products companies.
      - ndesaulniers 7y ago
        Point is I'm not going to create a FAT partition on my disk then go work out of it.
        darkpuma 7y ago
        Maybe you won't, but other people do. Dropbox and similar services have eaten away at the practice, but a lot of people still walk around with flash drives, partition table untouched since they bought it, with all their personal and work files. Not merely just using it to transfer large photographs or pirated movies, but keeping their de facto 'home directory' in that flashdrive. For a few years in the mid to late 00s, it seemed like almost everybody was doing this. Before that, I knew people who did it with zip drives. And I even once knew a guy who tried it with DVD-RAM, but gave up pretty quick.

kazinator 7y ago

If include <version> in angle brackets finds some Autoconf VERSION detritus, it's because the compiler has been wrongly told to look for <...> headers locally. (Probably by the same Autoconf junk.) There is a (not so) modern (any more) gcc option -iquote to specify a directory to search for #include "..." without affecting #include <...>. In the TXR project I have a "signal.h" local file: http://www.kylheku.com/cgit/txr/tree/signal.h http://www.kylheku.com/cgit/txr/tree/signal.h Yet, <signal.h> is also included. Like in this file: http://www.kylheku.com/cgit/txr/tree/signal.c http://www.kylheku.com/cgit/txr/tree/signal.c which has both #include <signal.h> and #include "signal.h". This is fine, if you know what you're doing. #include <signal.h> has no business finding that local file, and will not do so, unless someone screws up.