Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 (Fortune 01.1b1); site graffiti.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!ut-ngp!shell!graffiti!peter
From: peter@graffiti.UUCP (Peter da Silva)
Newsgroups: net.lang.c
Subject: ANSI 'C'.
Message-ID: <447@graffiti.UUCP>
Date: Sun, 17-Nov-85 21:45:53 EST
Article-I.D.: graffiti.447
Posted: Sun Nov 17 21:45:53 1985
Date-Received: Tue, 19-Nov-85 05:46:55 EST
Organization: The Power Elite, Houston, TX
Lines: 24

I finally got hold of a copy of the new proposed standard (thanks Stanley!),
and would like to point out a problem with it: it's a prescriptive rather
than a descriptive standard. Now I know ANSI has acquired a habit of making
prescriptive standards lately, but at least there had been a pre-existing
descriptive standard to work from. Oh well.

I would also like to point out that there are several UNIX-like functions in
the library that are inappropriate for most non-UNIX implementations of 'C'.
In particular, the time functions (ctime(3) in the UPM) are unimplementable
in many systems, due to the lack of a daylight savings flag in the O/S. Would
it be acceptable to seperate O/S and language library functions so that non
UNIX environments can support ANSI-C?

Finally, if \v is to produce a vertical tab, does that require the I/O library
to include termcap so that the various output devices that implement this
function in various ways can be accomodated?

Basically, the standard is far too specific... it prescribes actions that are
strictly outside the definition of the language.
-- 
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!peter