Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <7691@brl-smoke.ARPA>
Date: 15 Apr 88 01:20:36 GMT
References: <152@ghostwheel.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

In article <152@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>Now, however, X3J11, in the interest of runaway optimization, has exploded
>the name space of the language by reserving a whole host of function, macro,
>and data names.  While it is true that almost everyone wants standard libraries
>with their C compilers which match the libraries developed over the years on
>systems running the various flavors of Unix, I can't believe a majority of C
>programmers want these library definitions rolled into the language.

I don't believe you could have studied the proposed standard before posting
this nonsense.  How would "exploding the name space" possible serve the
interest of "runaway optimization"?  X3J11 introduced only three names
that could be considered to be motivated by considerations of optimization,
namely the three type qualifiers.  One of them has a chance of being withdrawn
next week, another's main purpose was to permit ROMable data generation, and
the third's main purpose is to DISABLE optimization.

As to the headers, ANSI C provides a much more controlled name space than
traditional practice (which varied widely among implementations).  In fact
the cleanliness of this name space became a substantial issue between X3J11
and IEEE 1003.1, who were prohibited from introducing additional names via
the standard headers.  The library functions that are being standardized for
use in hosted environments are the ones that in fact programmers have wanted
to have available everywhere, rather than having to carry around their own
private libraries (which would not be able to implement good system interfaces
in a portable manner anyway).  There have been a few new functions created in
order to support programming in an "internationalized" environment, but the
vast majority were based on common (but not universal) existing practice.  In
fact my pre-ANSI C applications depend on the availability of most of these
library functions; I'll be glad to have them become universally available.

Definitions such as those in <limits.h> (which is NOT an X3J11 invention)
only take effect if you include the header, and in any case the totality
of the standardized symbols is relatively small and well-defined.  Since
there are no vendor-specific symbols (other than a few special forms that
can be easily avoided) defined by including standard headers in an ANSI C
conforming environment, there is much less to worry about when developing
maximally portable applications.  Anyone who has ported many applications
across widely divergent C environments should be able to appreciate what an
improvement this will be!

If you really want a "free-standing" environment (free of library functions),
that is one of the two environments provided for in the standard.