On 06/18/2011 04:18 PM, James Youngman wrote: >> Should we guarantee that PATH_MAX is a constant expression (by modifying >> lib/pathmax.h), or change tests/test-stat.h to not assume it? > > It looks to me like POSIX doesn't state that PATH_MAX is a constant > expression. There are other values in limits.h that POSIX states > must be constant expressions (for example, INT_MAX) so I think this is > deliberate.
POSIX states that PATH_MAX, if defined, must be a compile-time constant. It must not be defined if it is not a constant, in which case is it determined at runtime via pathconf() and friends (if there is a limit). > I suspect that the most useful thing we can do in gnulib is define > PATH_MAX to a non-constant expression on all platforms, even the ones > in which it is normally a constant expression. Rather, I would almost rather explicitly undefine PATH_MAX in gnulib headers, to force programs to portably build without making any PATH_MAX assumptions; this also fixes bugs where stack-allocating PATH_MAX bytes (on systems where PATH_MAX is a constant) causes undesirable stack overflows. But we don't have a working [f]pathconf() in gnulib yet, so undefining PATH_MAX would be a step backwards for most other systems. So Bruno's current patch to guarantee a (constant) PATH_MAX on HP-UX seems like the right thing to do for now. > Otherwise maintainers > will find that their code works on their system but won't compile on > some other system they don't have access to. Clearly this position > on PATH_MAX could be taken to its logical conclusion of un-defining > the macro on all platforms to make sure that all GNU programs work on > Hurd, but I think that discussion has already been had. In any case, > maintainers who want to go in for this can probably achieve the same > sort of effect with a syntax check. About the only way I can see to portably use PATH_MAX is as an optimization hint - algorithms that operate on an unknown length path can start with a reasonable allocation (say 4096), and reduce that allocation on platforms where PATH_MAX is constant but smaller. Direct allocation (via declaration or malloc) of an array of PATH_MAX bytes is wrong; it fails on systems where there is no limit (such as Hurd), so you already have to write your algorithms to gracefully deal with arbitrary lengths, where the common cases are handled via your initial guess (a guess of 4096 or slightly less is nice, especially since it can be stack-allocated), and fall back to handle longer names on the platforms where longer is possible. > As for tests/test-stat.h, I'm mildly surprised that we haven't seen > any systems where an auto buffer of size PATH_MAX blows the stack. I'm looking into fixing that test. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
