Bruno Haible wrote: >> Bruno's comment (in the text you elided) suggests intent to have >> pathmax.h leave PATH_MAX undefined on the Hurd: >> >> >> I find it reasonable to use "#ifdef PATH_MAX" in front of every use of >> >> PATH_MAX, like POSIX requires. >> >> With such a change, each of the above uses would evoke a syntax error. > > A package like coreutils can also do > #ifndef PATH_MAX > # define PATH_MAX 8192 > #endif > in its system.h.
Of course. It should stop including pathmax.h and do that regardless. And I don't mind adapting. In fact, I've just made the change. Just wanted to make sure you realize that what you propose would change long-standing policy. > Looking at both uses of PATH_MAX in coreutils (src/pwd.c:88 and > src/remove.c:186) the value of PATH_MAX is capped by 8192 or 16384 anyway. > So, on systems like GNU/Hurd, where filenames can have arbitrary size, you > are calling pathconf for no real purpose. > > To me, this confirms that a generic pathmax.h (like the one in gnulib) > should only define PATH_MAX when it makes sense - like POSIX says -, > and that the handling of the GNU/Hurd case should be done on a case-by-case > basis: > - Either a package-wide handling, or a per-file handling. > - Either a fallback value of 8192, or a fallback value of > pathconf ("/", _PC_PATH_MAX), or just a #ifdef test.