ANSI C.

[Henry Spencer]

> Simply because they have been around for a long time, doesn't
> mean that they are the best way of doing things; and simply
> because UNIX does it that way, doesn't mean that everyone else
> should do it that way.  This is supposed to be a C standard,
> not a make-the-world-look-like-UNIX standard.

This is supposed to be a C standard, not a make-the-world-look-the-way-
Ray-wants-it-to standard.  That means one uses existing conventions, even
if they are a bit silly, rather than gratuitously inventing new ones.
People implementing gmtime() have generally followed the Unix conventions.
Note that the pointer convention of gmtime() etc. doesn't actually hurt
anything; it is silly in a modern context, but that is not sufficient reason
to "fix" it and thus break every program that ever used it.

> I understand why they originally took pointers; but the need
> is no longer there.  Now is the time to correct old mistakes
> not propagate them.

Why, exactly, does this need fixing so badly?

> A number of other functions are defined
> by the standard that differ from the same functions on UNIX
> (at least some versions of UNIX) and people are going to have
> to make a number of changes to their code anyway.

Name three.  If you mean that the standard defines functions which are
preferable to the UNIX ones, and that UNIX programs should be redone to
use the new ones, that's a different story.  My information may be out
of date, but I'm not aware of *any* functions in the drafts I've seen
that are inconsistent with UNIX usage to the point of breaking code.
Not breaking existing legal code was a major objective of the committee!

> I know that for anything I write I already have a cover function
> for ctime(), so that I can use ctime(time()) without having to
> go through the bother of allocating a temporary variable...

I trust that you're being informal for the sake of explanation, rather
than claiming that you use the name "ctime" for your new function, or
that you call time() without a parameter (which is wrong).

> One of the biggest problems with the K&R C manual is the things
> that it doesn't explicitly mention...  Please don't make this new
> standard work the same way...If something is implementation dependent then
> the standard should explictly say so.

This is one of the reasons why writing the X3J11 drafts is much harder
work than writing appendix B of K&R -- there really is a major attempt to
be precise and complete.  But the standard really cannot say "the values
of CLK_TIM and BUFSIZ are unrelated even though one happens to be ten times
the other" (to pose a silly hypothetical case); it is impractical to
disclaim everything, the document becomes unreadable.  People using the
language must rely on what the standard says and *not* rely on what it
doesn't say.  The best the standards-writers can do is to make the more
obvious and conspicuous non-relationships explicit.  Note also that the
words "implementation-dependent" in an X3J11 draft have a specific meaning:
they mean that the implementor can make the decision as he wishes BUT IT
MUST BE DOCUMENTED.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry