[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. > > In any case, it looks like your patch is ok, since the combination > of these two blocks ensures that PATH_MAX *is* always defined: > > # ifndef _POSIX_PATH_MAX > # define _POSIX_PATH_MAX 256 > # endif > > # ifndef PATH_MAX > # define PATH_MAX _POSIX_PATH_MAX > # endif On Hurd, if we are going to insist on a constant PATH_MAX definition for use as a hint, then we probably ought to end up with a PATH_MAX value more like 1024 or 4096 rather than a paltry 256, so that coreutils' pathchk.c doesn't reject a 257-byte path as being smaller than PATH_MAX (this would be a regression for pathchk without options). -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
