ANSI C.

[Peter da Silva]

> I think the concept of DST is stupid, but so long as
> it has to be dealt with, some means must be provided.

Perhaps, perhaps, but it'd be better to leave that up to the application
instead of stuffing the library or forcing some PC user to create a file
at certain times of the year just to run some program that happens to be
written in 'C'. In addition, the X3J11 draft I read explicitly stated time_t
was a number of seconds, not a magic cookie that had to be difftime()-ed
if one wanted to do comparisons. Even if it is, on other systems floating
point support is relatively expensive in terms of memory, which would make
difftime() an unnaceptable burden on the implementor.

The basic complaint is that X3J11 is not a description of 'C', but rather a
description of 'C' under UNIX. There is a good deal of stuff in it that
should not be in the language definition, but rather in a standard
extension: the UNIX compatibility package, for example. I like UNIX, and
I'd like nothing better than to see it become the standard O/S for non
real-time applications (how does one deal with the DST in some little
standalone 'C' program in an RTU in Oman somewhere? They don't even use
it...), but I don't expect it to happen. I like 'C', and I sure hope that
it doesn't become restricted to UNIX and UNIX-like systems.

That's what I see happening, however, unless X3J11 is (a) ignored or (b)
fixed. And I hope that if they don't (b) fix it, everyone else follows my
example and (a) ignores it.
-- 
Name: Peter da Silva
Graphic: `-_-'
UUCP: ...!shell!{graffiti,baylor}!peter
IAEF: ...!kitty!baylor!peter