This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix allocation limit for getcwd syscall


> PATH_MAX only limits the length you can pass to functions taking a file
> name.  It does _not_ limit the length of absolute names of files in the
> system.  The coreutils testsuite explicitly tests for the ability to
> determine the name of the cwd when it exceeds PATH_MAX.

I understand the reality of what getcwd can produce, and the implementation
reasons why it is difficult to constrain the length of a directory name
that can exist.  However, your statement is not an accurate
characterization of what POSIX says.  It says "absolute pathname" in the
specification of getcwd.  In 3.266 it defines the term "pathname", and
says, "... a pathname consists of, at most, {PATH_MAX} bytes, including the
terminating null byte."

> > That said, I don't think the code should presume what the kernel
> > implementation does in this regard.  It should do something other than
> > crash when it gets ERANGE.
> 
> PAGE_MAX has always been the limit that the kernel imposes on getcwd.  It
> was wrong to use PATH_MAX in the first place.

This statement has no bearing on my point.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]