Date: Fri, 17 Jan 2003 17:06:08 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib realpath.3 realpath.c src/bin/realpath realpath.c Message-ID: <200301172206.h0HM68lZ081733@khavrinen.lcs.mit.edu> In-Reply-To: <20030116.105850.128048106.imp@bsdimp.com> References: <20030116051916.E58850@espresso.q9media.com> <20030117033631.F3152-100000@gamplex.bde.org> <20030116.105850.128048106.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 16 Jan 2003 10:58:50 -0700 (MST), "M. Warner Losh" <imp@bsdimp.com> said:
> Even in the MAXPATHLEN case, there are potential problems. It
> wouldn't work if, say, the stack was exhausted when the function was
> called. You have to draw the line at some classes of errors and say
> they won't happen enough to be worth the effort it is to code them up.
In the general case, POSIX programs must work when there is no
{PATH_MAX} limit at all (that is to say, pathnames are not limited in
length).[1] There is a known bug in the standard for this particular
function that it does not provide a way of dealing with this. The
result of the interpretations process was a recommendation that
implementors implement the GNU libc extension, whereby a null
`resolved_name' parameter causes the function to allocate enough space
on its own -- this will probably be included in the next major
revision of the standard.
-GAWollman
[1] The GNU Hurd is an operating system on which this is true, and it
was the Hurd developers who first pointed out this error in the
standard. Unfortunately, this problem was identified too late in the
process to fix it in the 2001 revision. The Standard does in general
allow for the absence of a limit on pathname length.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301172206.h0HM68lZ081733>