From owner-cvs-all Fri Jan 17 14: 6:14 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A67EB37B401; Fri, 17 Jan 2003 14:06:13 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E5A443EB2; Fri, 17 Jan 2003 14:06:12 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0HM68CJ081736 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 17 Jan 2003 17:06:09 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0HM68lZ081733; Fri, 17 Jan 2003 17:06:08 -0500 (EST) (envelope-from wollman) Date: Fri, 17 Jan 2003 17:06:08 -0500 (EST) From: Garrett Wollman Message-Id: <200301172206.h0HM68lZ081733@khavrinen.lcs.mit.edu> To: "M. Warner Losh" 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 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> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < 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