[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
signature.asc
Description: OpenPGP digital signature
- Re: PATH_MAX constant expression,
Eric Blake <=