Re: PATH_MAX constant expression

[Jim Meyering]

Eric Blake wrote:

> [adding coreutils]
>
> On 06/20/2011 10:51 PM, Jim Meyering wrote:
>>>> 2011-06-20  Bruno Haible  <address@hidden>
>>>>
>>>>    pathmax: Never define PATH_MAX to a non-constant expression.
>>>>    * lib/pathmax.h (PATH_MAX): Don't define in terms of pathconf.
>>>>    * m4/pathmax.m4 (gl_PATHMAX): Don't test for pathconf.
>>>
>>> Looks okay to me, but let's wait to see if anyone else also has an
>>> opinion.  Let's also enhance doc/posix-headers/limits.texi to mention
>>> the pathmax module and its (new) semantics of not interfering with Hurd.
>>
>> coreutils has few remaining uses of PATH_MAX, but they do expect
>> pathmax.h to define it unconditionally, and from what I recall,
>> it has always worked that way.  Thus, changing it *not* to define
>> PATH_MAX on the Hurd would cause trouble.
>
> As is, coreutils' src/pathchk.c appears safe (it checks whether a value
> is less than PATH_MAX), although see below.
>
> sys/remove.c uses PATH_MAX safely, as a hint for an initial start size
> via MIN (PATH_MAX, 8192).
>
> src/pwd.c appears to have a bug: it tries to use PATH_MAX as a hint, via
> MIN (2 * PATH_MAX, 32 * 1024), but if PATH_MAX is INT_MAX, then this
> overflows, with awkward consequences.  Thankfully, PATH_MAX is never
> INT_MAX in any known use of pathmax.h, but we ought to avoid even the
> potential for that problem.
>
> But none of these points use char foo[PATH_MAX]; so it does seem simple
> enough to add a syntax check to ensure that PATH_MAX is never used as an
> array bound.

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.