From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22774 invoked from network); 9 Aug 2000 14:25:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Aug 2000 14:25:24 -0000 Received: (qmail 12958 invoked by alias); 9 Aug 2000 14:25:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12575 Received: (qmail 12951 invoked from network); 9 Aug 2000 14:25:07 -0000 Date: Wed, 9 Aug 2000 10:25:01 -0400 From: Clint Adams To: Bart Schaefer Cc: zsh-workers@sunsite.auc.dk Subject: PATH_MAX vs. _PC_PATH_MAX vs. POSIX (was Re: PATCH: tail-dropping in files module mkdir) Message-ID: <20000809102501.A24977@dman.com> References: <20000804204021.A7925@dman.com> <1000804070216.ZM23696@candle.brasslantern.com> <20000804091955.A4368@dman.com> <000804111549.ZM28988@candle.brasslantern.com> <20000804205227.B7925@dman.com> <1000805044825.ZM29238@candle.brasslantern.com> <20000807140445.A15891@dman.com> <000807133944.ZM26497@candle.brasslantern.com> <20000808074007.A7961@dman.com> <000808144749.ZM7078@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <000808144749.ZM7078@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Tue, Aug 08, 2000 at 02:47:49PM -0700 > The definition of pathconf(dir, _PC_PATH_MAX) is inherently incompatible > with the definition of the PATH_MAX constant. The latter is the maximum > length of an absolute path from the root [*], the former approximates the > same constant minus the length of [the equivalent of] realpath(dir). Well, I've seen two or three manpages that list _PC_PATH_MAX as being "relative path from cwd", and nothing that claims that PATH_MAX is anything more meaningful than "maximum path length". FreeBSD doesn't make the relative claim; it just says _PC_PATH_MAX The maximum number of bytes in a pathname. But, it will actually go to the directory in the first argument, determine it's filesystem, and ask the filesystem driver's pathconf() for a value. As usual, I don't have access to POSIX (and it seems all the old drafts that were available online have been recalled), but SUSv2 says (http://www.unix-systems.org/single_unix_specification_v2/xsh/limits.h.html) PATH_MAX Maximum number of bytes in a pathname, including the terminating null character. Minimum Acceptable Value: _POSIX_PATH_MAX On the other hand, SUSv2 pathconf(), (http://www.unix-systems.org/single_unix_specification_v2/xsh/fpathconf.html) which is "derived from POSIX-1.1988", both links PATH_MAX with _PC_PATH_MAX, but it also has the same notes we saw in either HP/UX or Solaris. Those would be 4.If path or fildes does not refer to a directory, it is unspecified whether an implementation supports an association of the variable name with the specified file. 5.If path or fildes refers to a directory, the value returned is the maximum length of a relative pathname when the specified directory is the working directory. > Suppose pathconf() returns a constant value == _POSIX_PATH_MAX no matter > what its directory argument is. Comparing strlen(realpath(dir)) to that > constant tells you if the filesystem will ultimately reject the name, but > comparing strlen(dir) tells you nothing. > > Now suppose pathconf() returns a differing amount depending on the length > of realpath(dir). In this case comparing strlen(realpath(dir)) to that > value is entirely wrong, because pathconf() has already accounted for the > real path! Even comparing strlen(dir) doesn't tell you anything, because > what the value reflects is how much *more* path space you have left after > you already have used whatever it takes to get to realpath(dir), whereas > strlen(dir) gives some fraction of the already-used path space. Back to the pathconf() manpage from SUSv2, we have |If the variable corresponding to name has no limit for the path or file |descriptor, both pathconf() and fpathconf() return -1 without changing |errno. If the implementation needs to use path to determine the value |of name and the implementation does not support the association of name |with the file specified by path, or if the process did not have |appropriate privileges to query the file specified by path, or path does |not exist, pathconf() returns -1 and errno is set to indicate the error. So it appears that the implementation has the option of caring about the first argument or completely ignoring it. > If somebody with access to the POSIX spec can refute that last paragraph, > I'll be thrilled. I hope they've made some clarifications since 1988. > In the meantime, we have to detect the constant-valued pathconf() in order > to determine whether we should do a comparison, because comparing to a > context-dependent pathconf() value is wrong. It could be an autoconf check if you can think of a path guaranteed to be invalid. > Hard to say. It's going to take a LOT of rewriting; it might be better > not even to pretend to support pathconf() until that rewriting is done. > > [*] Or at least zsh has always treated it as if that's the definition. It seems to me as though, at least according to what I understood of some X/Open specs, it's intended as a maximum argument length to library functions.