Re: PATH_MAX constant expression

[Jim Meyering]

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.