From owner-cvs-all Sat Jan 29 20:43:29 2000 Delivered-To: cvs-all@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id BC28F150C9 for ; Sat, 29 Jan 2000 20:43:24 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 22944 invoked from network); 30 Jan 2000 04:43:21 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 30 Jan 2000 04:43:21 -0000 Date: Sun, 30 Jan 2000 15:43:17 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Garrett Wollman Cc: obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen Makefile.inc In-Reply-To: <200001292230.RAA35707@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Sat, 29 Jan 2000, Garrett Wollman wrote: > < said: > You quote precisely the section which proves my point. > > > Section 4.13.7 General Utilities > > > Function names that begin with {\bf str} and a lowercase letter > > (followed by any combination of digits, letters, and underscore) may > > be added to the declarations in the header. > > Nowhere in this paragraph does it say ``by ANSI/ISO''. Um, this is implicit in in the section being a subsection of "Future library directions". > These are > identifiers which are prohibited to *users*, not to The > Implementation. Right. They are, technically, precisely as prohibited to users and unprohibited to The implementation as most identifiers beginning with 2 underscores (except for one slike __STDC__), i.e., completely prohibited to users and completely unprohibited to The implementation. > (This should be obvious: the only way a new such > identifier would be added to the standard is if it first appears in some > implementation.) However, implementations should be more careful selecting names and interfaces for extensions than for double-underscored implementation details, especially if they want the extensions to be adopted by a future standard. Applications are actually allowed to use extensions. This "works" as follows for strdup(): - use of strdup() gives undefined behaviour in Standard C and POSIX. - undefined behaviour can be anything, including what you want. FreeBSD currently defines the behaviour of strdup() to be something reasonable. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message