bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATH_MAX and test-stat.h


From: Eric Blake
Subject: Re: PATH_MAX and test-stat.h
Date: Mon, 20 Jun 2011 11:46:07 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]