From owner-cvs-all  Thu Jan 16  8:44:45 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 49E5B37B405; Thu, 16 Jan 2003 08:44:44 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 63DD543F5F; Thu, 16 Jan 2003 08:44:42 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA04927;
	Fri, 17 Jan 2003 03:44:32 +1100
Date: Fri, 17 Jan 2003 03:45:41 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Mike Barcroft <mike@FreeBSD.org>
Cc: "M. Warner Losh" <imp@bsdimp.com>, <johan@FreeBSD.org>,
	<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: <20030116051916.E58850@espresso.q9media.com>
Message-ID: <20030117033631.F3152-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

On Thu, 16 Jan 2003, Mike Barcroft wrote:

> M. Warner Losh <imp@bsdimp.com> writes:
> > In message: <20030115183943.D58850@espresso.q9media.com>
> >             Mike Barcroft <mike@FreeBSD.org> writes:
> > : Hmm, I thought it was more complicated than this.  IIRC, PATH_MAX
> > : isn't necessarily available at compile-time, so it needs more
> > : complications to conform to POSIX in the case where PATH_MAX isn't
> > : defined.  Portablility might not be important, in which case it
> > : isn't clear why we would change from MAXPATHLEN to PATH_MAX or vice
> > : versa.
> >
> > I made this change because PATH_MAX is more posixly correct than
> > MAXPATHLEN and has a better definition.  It only handles the case
> > where PATH_MAX is a compile time constant, or when you are using gcc
> > extensions that allow one to allocate memory on the fly.
>
> Fair enough.

Only {PATH_MAX} has a better definition, but we use PATH_MAX.  gcc
extensions don't handle the case where PATH_MAX is not a compile time
constant.  "char wbuf[PATH_MAX];" doesn't compile if PATH_MAX is not
defined.  "char wbuf[sysconf(_SC_PATH_MAX)];" would fail to handle the
cases where sysconf() returns an error.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message