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