Donn, Andries, & Geoff,
I believe that if you look closely at the current standard, you
will find that the minimum supported PATH_MAX value is 256
{_POSIX_PATH_MAX} for POSIX systems and 1024 {_XOPEN_PATH_MAX} for UNIX
systems (or more correctly for POSIX systems supporting the XSI
option). But, there is no upper limit according to the standard.
{PATH_MAX} is defined in the Pathname Variable Values section of
<limits.h> which means that if PATH_MAX is not defined in <limits.h>
applications are required to use
pathconf(directory_name, _PC_PATH_MAX)
or
fpathconf(directory_fd, _PC_PATH_MAX)
to get the value of PATH_MAX for pathnames in any specific directory.
And, if these [f]pathconf() calls return -1L without changing errno,
the standard says it means that there is no limit. If there is no
PATH_MAX limit in a directory, a chdir() would never fail with
ENAMETOOLONG unless a component of the path exceeded NAME_MAX. (Note
that the standard also specifies that NAME_MAX could also be
unlimited.)
Unfortunately, however, thousands of application programs won't
build if PATH_MAX isn't defined in <limits.h> (no matter what the
standard says) and thousands more binaries out there will stop working
if the PATH_MAX limit increases. Many ABIs also specify specific
PATH_MAX values. Therefore, make it difficult for many implementations
to raise or remove the limit.
So, let's not expand the problem beyond what Geoff originally
raised. The standard needs to allow the shell's cd built-in to
navigate arbitrarily deep directory hierarchies. The chdir() function
is fine here, we just need to allow (or maybe require) that cd make
however many calls to chdir() (with relative path arguments) are
required to get to the target directory rather than failing if a single
call to chdir() with an absolute path argument would fail due to path
length restrictions.
At this point, I expect that Geoff's aardvark will be treated
as an interpretation request. Unless I see something that leads me to
a different conclusion, I expect the interpretation will essentially
say the standard is clear and the standard is wrong. If Geoff can give
us suggested wording changes to be included as editor's instructions
for a future revision, I imagine the interpretation will be resolved
fairly quickly.
Cheers,
Don
>Return-Path: <yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx>
>Resent-Date: 7 May 2004 16:23:06 -0000
>Date: Fri, 7 May 2004 18:22:31 +0200
>From: Andries Brouwer <yyyyyyyyyyyyyyy@xxxxxx>
>To: Donn Terry <yyyyyy@xxxxxxxxxxxxxxxxxxxxx>
>Cc: Geoff Clare <yyy@xxxxxxxxxxxxx>, yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Subject: Re: cd, relative paths, and PATH_MAX
>Content-Disposition: inline
>User-Agent: Mutt/1.4i
>X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.63
>Resent-Message-ID: <yyyyyyyyyyyyyyyyyyy@xxxxxxx>
>Resent-To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-From: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>X-Mailing-List: austin-group-l:archive/latest/6906
>X-Loop: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-Sender: yyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>
>On Fri, May 07, 2004 at 09:03:16AM -0700, Donn Terry wrote:
>
>> It probably remains true today with at least most file systems that the
>> directory tree can be arbitrarily deep.
>
>Yes, a good thing.
>
> The chdir() function shall fail if:
>
> ENAMETOOLONG
> The length of the path argument exceeds {PATH_MAX}
> or a pathname component is longer than {NAME_MAX}.
>
>I would prefer to have "may fail" here.
>
>It is better to have a guaranteed minimum rather than a guaranteed maximum.
>
>In reality there is not really any reason why there would have to be any
>upper bound. A simple change in current systems would suffice to make
>them handle path names of arbitrary length with components of arbitrary
>length (or return ENOMEM).
|