Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jan 2000 15:43:17 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc/gen Makefile.inc
Message-ID:  <Pine.BSF.4.21.0001301510050.447-100000@alphplex.bde.org>
In-Reply-To: <200001292230.RAA35707@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Jan 2000, Garrett Wollman wrote:

> <<On Sat, 29 Jan 2000 13:51:34 -0800, "David O'Brien" <obrien@FreeBSD.org> said:

> You quote precisely the section which proves my point.
> 
> > Section 4.13.7 General Utilities <stdlib.h>
> 
> >     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 <stdlib.h> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001301510050.447-100000>