Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP Path: utzoo!watmath!rbutterworth From: rbutterworth@watmath.UUCP (Ray Butterworth) Newsgroups: net.lang.c Subject: Re: ANSI C. Message-ID: <250@watmath.UUCP> Date: Wed, 27-Nov-85 15:51:22 EST Article-I.D.: watmath.250 Posted: Wed Nov 27 15:51:22 1985 Date-Received: Thu, 28-Nov-85 03:48:21 EST References: <3502@brl-tgr.ARPA> Organization: U of Waterloo, Ontario Lines: 72 > gmtime(), like time(), ctime(), and localtime(), takes a > pointer to a time_t because that's what they already do. > These functions have been defined (in UNIX at least) for a > long time (no pun intended). 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. 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. 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. It wouldn't be that difficult for the standard to define these functions with completely different names. Systems that never had the functions before can simply implement them as required, while systems that have similar functions can either provide macros or cover functions for mapping the one name and syntax into the other until the general population gets used to the new names. 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 that I can take the address of. > difftime() accepts time_t arguments but returns a double. > Its result is expressed in SECONDS, whereas a time_t is not > necessarily expressed in seconds. There is no portable way > to do simple arithmetic on general time_t values to produce > a time difference in seconds, hence difftime(). OK, this was my misreading of the standard. The problem was that it introduced CLK_TCK, clock_t, and time_t together, and it wasn't obvious to me that CLK_TCK wasn't the conversion factor between the two. I wasn't the only one that made the same mistake. There really should be a note here that the meanings of the values of time_t are implementation defined. One of the biggest problems with the K&R C manual is the things that it doesn't explicitly mention. It often takes a student of theological research to find the various hints and put them together to make a definite rule. Please don't make this new standard work the same way. i.e. don't leave the readers with the idea that "if we didn't mention something, then you can do what you want with it". If something is implementation dependent then the standard should explictly say so. If something isn't defined in the standard then we should assume that this was an omission to be corrected in the future, not a deliberate loophole that every implementor is free to interpret as he wishes. > Seems to me they put more thought > into it than some of their detractors.. True. If I want to make a public fool of myself, that only concerns me. But if the standards are sloppy, then that is everyone's business. This is supposed to be a scientific document giving precise rules; it isn't supposed to be the bible for some religion of C-worshippers who will spend hours pondering its mysteries and trying to interpret its hidden meanings. Just look at the articles that continually appear in this news group. Far too many of them are discussions about what K&R really meant when they said such-and-such, and proofs using quotations from three different sections of the book to show what they really had in mind. Probably at least half of the articles in any year are more or less identical with half the articles in any other year. Wouldn't it be nice to have a document which explicitly tells us how things are supposed to be instead of one which encourages such time-wasting discussions?