ANSI 'C'.

[Ron Natalie <ron>]

> 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.

Crapola, ANSI standards are almost always based on some existing work.  But
anything that's done by committee is likely to get riddled with a lot of
self interests.

> 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?

Eh?  The timezone never belonged in the operating system!  Unix time is GMT.
Most versions of UNIX these days use an environment variable to convey
timezone information to the user process.  All the C environment needs to
know is how to convert from GMT and LOCAL time to whatever the system uses
for time and back.  If you can't do this, it's likely to be impossible to
use times in C at all, regardless of how CTIME is specified.

> 
> 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?

Vertical TAB is an ASCII character.  If the terminal doesn't support it,
who cares.  Some terminals don't do horizontal tab either, you want to
pull \t?  My model37 won't do \r either.

-Ron