coreutils
[Top][All Lists]
Advanced

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

Re: PATH_MAX constant expression


From: Eric Blake
Subject: Re: PATH_MAX constant expression
Date: Tue, 21 Jun 2011 06:51:19 -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

[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.

> 
> 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   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]