Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  ANSI C.
Message-ID: <97@brl-tgr.ARPA>
Date: Tue, 26-Nov-85 18:05:09 EST
Article-I.D.: brl-tgr.97
Posted: Tue Nov 26 18:05:09 1985
Date-Received: Sat, 7-Dec-85 08:32:55 EST
Sender: news@brl-tgr.ARPA
Lines: 45

The thing is, the raw "language" part of C is (by design)
insufficient for programming real hosted applications,
so it must be extended with some library routines.  The
de facto set of library routines is a subset of those
found in the UNIX C library.  Certainly STDIO is generally
agreed upon, but there is more interaction with the host
environment needed than just file I/O.  Since a large
number of non-UNIX C implementations have provided much of
the UNIX C library, and since most of those library routines
are well-designed, it makes sense to standardize their
interface, patterned after the original UNIX routines but
with redefinitions as required to accommodate a wide variety
of operating system environments.

The Software Tools "Virtual Operating System" approach was
very similar (although accessed from RatFor, not C), and
their routines were also closely modeled after UNIX's.
This by no means constrained implementation to just UNIX
and its lookalikes; the VOS ran on just about every major
operating system, from micros to mainframes.  I haven't
noticed any real UNIX dependencies in X3J11's proposed
standard library routines.  Virtually everything they have
included are routines I frequently use in applications.
This applies no less to my Apple //e than it does for UNIX
systems.  In the past I have implemented similar libraries
for RT-11 and RSTS/E, and DEC's VMS C compiler provides
pretty much the same functions.

I agree that the C language standard should be independent
of UNIX, but I think it already is.  I see no point in
splitting the standard up into pieces, since portable
applications will require these routines anyway.  With
only a few very minor quibbles, I am happy with the X3J11
proposed draft standard and its general applicability to
virtually any hosted environment.  (Of course, your compiler
vendor may have some work to do to conform, but that's true
in any case.)

time_t is NOT seconds, in Doc. No. X3J11/85-045 (dated
April 30, 1985).  It IS an "arithmetic type", which does
seem like an oversight, since arithmetic on it cannot be
done portably (and structures can be assigned, passed as
function parameters, etc. so all necessary operations
work without requiring arithmeticity).  I think the
oversight needs to be remedied in the final standard.