Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re:  C Builtin Funxions
Message-ID: <530@brl-smoke.ARPA>
Date: Sun, 4-May-86 23:50:17 EDT
Article-I.D.: brl-smok.530
Posted: Sun May  4 23:50:17 1986
Date-Received: Thu, 8-May-86 04:37:03 EDT
References: <498@brl-smoke.ARPA> <182@cbmvax.cbmvax.cbm.UUCP>
Reply-To: gwyn@brl.ARPA
Organization: Ballistic Research Lab (BRL)
Lines: 46

In article <182@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>To minimize this criticism, the committee seems to be making a
>big distinction between hosted and non-hosted environments that
>doesn't map well into the real world.  Most of the people trying
>to develop compilers for non-unix microcomputer operating systems
>are trying to be as unix-like as possible, but just can't make
>all the way because of operating system brain damage.

Although based on a subset of the UNIX implementation, the X3J11
hosted C specification does not require support functions that
cannot be implemented on almost any popular operating system.
For example, I am sure that a conforming hosted implementation
is possible on my Apple //e.  There aren't many more primitive
systems than that!

>I would be much happier if there were two separate documents, so
>that a vendor could clearly say that his compiler is fully X3J11
>conforming, and his runtime support conforms to XJXXX with the
>following exceptions.

"Exceptions" are pointless when the hosted runtime support is
implementatble on essentially every system.

All the library functions pertain to the hosted environment only.
Only the "raw" C language is required in the stand-alone environment.
It didn't take X3J11 long to agree that it was as important to
standardize the hosted environment library functions as to
standardize the raw language.  I think that is essential; most
C porting problems I've encountered have been library and header
interface incompatibilities, not raw language problems.

>One of the better things to come out of the COBOL standards efforts
>was the notion of specifying a minimum core language, then defining
>optional modules that were pretty close to the way the big boys (IBM)
>had actually implemented their extensions.  This makes it fairly
>easy for a vendor to communicate to a user just what his compiler
>supports.

That is easier for a language with built-in I/O facilities.  In the
case of C, either an implementation is a conforming hosted ditto or
it is a conforming stand-alone ditto (no library functions) or it
is nonconforming.  That's about the right number of levels as far
as I am concerned.  There's no need for more (although it would be
nice to have standardized library additions for a variety of
things; however, the X3J11 document describes the minimum useful
language, not a superset of everybody's wish lists).