Eric Blake wrote: > [adding coreutils] > > On 06/20/2011 10:51 PM, Jim Meyering wrote: >>>> 2011-06-20 Bruno Haible <br...@clisp.org> >>>> >>>> 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.
