Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.lang.c Subject: Re: ANSI C. Message-ID: <151@brl-tgr.ARPA> Date: Thu, 28-Nov-85 19:25:59 EST Article-I.D.: brl-tgr.151 Posted: Thu Nov 28 19:25:59 1985 Date-Received: Sat, 30-Nov-85 00:51:13 EST References: <3502@brl-tgr.ARPA> <250@watmath.UUCP> Organization: Ballistic Research Lab Lines: 97 > 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. I suspect it was much easier to get the committee members to all agree on an acceptable definition that covered the functions already in use than it would be to get them to agree upon totally new interfaces to the time functions. Pointer parameters are not necessarily a "mistake", although they are not the best way to design these functions if one were to do so TODAY. The job of porting applications forward to the new X3J11 environment is much easier if it is compatible with the current (poorly defined) one. The fact of the matter is, most good commercial implementations of non-UNIX C provided UNIX-compatible library routines all along. The most notable exception was Whitesmiths, Ltd., and even then one could get a UNIX-compatible library from Plum Hall, Inc. The X3J11 standard is just defining what an application shall be able to count on in all conforming environments; those of us who have been hauling around our own C libraries will be glad to have them provided for us uniformly across all systems. > There really should be a note here that the meanings of the > values of time_t are implementation defined. Some clarification might indeed be helpful. The meaning of time_t data lies in how they are used, which the library function definitions explain. > 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. X3J11 has nicely addressed most of the ambiguities and omissions in K&R. I think it is implicit in any such standard that whatever has not been defined in the standard has no guarantees of any kind. There are uncountably more things not explicitly addressed by the standard than are addressed; it would be infeasible to anticipate them all. If you can identify some specific items that need to be addressed you should bring them to the attention of the X3J11 committee ASAP. I believe the intent is to specify no more and no less than the rules that MUST be followed by a conforming implementation. This implies that anything not specified must NOT be relied on by portable applications code. One need not guess. > 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. Agreed, except that "scientific document" is putting it too strongly. The standard represents a consensus of experts, and as such has compromises (like not insisting on the ASCII character set) and weaknesses (like not providing for variable dimensions on formal array parameters). What one hopes is that it will be "good enough" to promote a uniform C environment. My feeling is that it will be. Actually, K&R wasn't too bad, but one had to THINK and UNDERSTAND the ideas and "spirit" of the C language, and a lot of people obviously had trouble in these areas. X3J11 is much more explicit. > 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? Exactly. BUT don't expect that to stop idiotic postings to the news group. Many of them in the past could have been resolved by reading VERY CLEAR statements in K&R, but the posters didn't bother to look them up. I think part of the problem is that people are getting incorrect explanations from sources such as amateur hacker journals (and even this newsgroup!), and they don't realize that people propagating bogus information don't know what they're talking about. There is a lot of "unlearning" to be done if one has acquired C "knowledge" from such sources.