Xref: utzoo comp.std.c:2225 comp.lang.c:24218 Newsgroups: comp.std.c,comp.lang.c Path: utzoo!sq!msb From: msb@sq.sq.com (Mark Brader) Subject: Postings in comp.std.c and comp.lang.c Message-ID: <1989Dec4.193436.4613@sq.sq.com> Followup-To: the place you THINK most appropriate Summary: How to avoid flame wars. Malloc/free discussion criticized. Reply-To: msb@sq.com (Mark Brader) Organization: SoftQuad Inc., Toronto References: <7130@ficc.uu.net> <11363@smoke.BRL.MIL> Date: Mon, 4 Dec 89 19:34:36 GMT Peter da Silva, or a reasonable* facsimile thereof :-), writes of a particular argument in comp.std.c: > Doug, Norman. Chill out. ... [It's just that] Norm is (for whatever > reason) having trouble making sense of parts of the standard [and] Doug is > (for whatever reason) having trouble seeing how Norm could be confused. I agree with his assessment of the misunderstanding in question, and would like to suggest a few guidelines for avoiding this sort of thing in the future. The following remarks apply to questions of the form "Is the following example legal/portable C?", "What is the right way to do the following?", and similar topics. If you're posting a question about the proposed** ANSI C Standard (pANS), please say specifically that that IS what you are talking about, and post to comp.std.c only. If you're asking what was the Committee's intent or why they decided as they did, or whether a particular section constitutes a bug (i.e. something that simply does not say what the Committee meant it to say), then say what you mean without sarcasm. And if you have a draft Standard at hand and are asking about the meaning of a specific bit of it, then CITE it, by date and section number, and preferably giving page and line or exact wording. Conversely, if your question does NOT particularly pertain to the pANS, post to comp.lang.c, and if possible tell whether you are interested in an answer portable to all existing implementations, specific to one implementation, relating to historical background, or what. (Questions from those who are novices at C and haven't been reading the group for at least a few months are very likely to repeat earlier items and should not be posted worldwide, or even USA-wide. It's best to seek help locally first; if you can't get any, try posting with regional distribution, e.g. to Ontario or California, and say in the article body that you're doing that. You could also try picking someone who posted an article you thought answered some question well, and simply emailing to them. Some of us don't mind a small volume of that sort of thing.) If you're answering a question in comp.lang.c, please do NOT assume that a pANS reference suffices, unless the original poster SAID SO; try to give an answer that is applicable across as many implementations as are relevant. A citation from the pANS or K&R 1, or other less definitive references, is usually desirable but if you cite one you should point out the limits of its authoritativeness. Also, please DO NOT POST answers on questions of fact unless you feel that you are in a better position to speak authoritatively than almost anybody else who is likely to answer. If you're not sure about that, then WAIT a couple of days before posting, or mail to the original questioner and ask THEM to post if they don't see a better posted answer. If you're answering a question in comp.std.c, a citation from the pANS is virtually mandatory -- in detail, as I said above. I say "virtually" because there will be cases where the answer is "the pANS says nothing about this", and as the man said, there's nothing at all to be done about that. The pANS is a damned good piece of work but even so it contains some wording that can be quite misleading on first reading, as well as some things that I consider to be bugs (as defined above) It is worthwhile taking some time to be sure that you really understand what a particular section says before posting it, AND TO PASS ON that understanding to your audience by explicating in your posting any tricky points. As an instance of how NOT to conduct a discussion, I point to the recent one about a "common malloc/free practice". I avoid naming names here because I am criticizing the writings and not the writers, and it's possible that I am remembering some details wrongly, in which case you may treat this as a fictitious example of how not... The original poster (say "Q") said something of this form: "It is common in existing code to do the following, but I cannot see anything in the pANS to say that it is guaranteed to work. Is it?" For those who missed it, the code in question was of the form TYPE *ptr = malloc (size); /* code using ptr here */ free (ptr); where I omit the usual casts since they are not necessary in pANS C, and where TYPE is some type with alignment requirements. The question was whether the pANS wording instead required the value returned by malloc() to be saved in a variable of type void * before being converted to TYPE *, just so that that unconverted value could eventually be passed to free(): void *svp = malloc (size); TYPE *ptr = svp; /* code using ptr here */ free (svp); Unfortunately, "Q" posted the question to comp.lang.c as well as comp.std.c, and (I think) did not state very clearly what the actual point at issue was. This led to a flock of followups that ignored the fact that the question was about the pANS, justifying the first version of the code in terms of manuals for existing releases, and the like. Many of these followups went to comp.lang.c only. Many OTHER followups went to comp.std.c only. A person whose postings are usually authoritative but terse (say "A") posted in comp.std.c something of the form "Nonsense, the pANS doesn't require that; why would the Committee do that? The first version is fine." There were several rounds of confused postings and "Q" eventually said that he never thought the Committee intended to require code of the form of the second example above; he was only pointing out what he thought was a bug in the pANS. How much simpler if he had said that in the first place! Along the way people had finally started to post section numbers from the pANS and then actual quotations. But "A" continued to maintain that the pANS "does not require that", and similar flat statements. By now several people who had seen what "Q" was originally driving at were starting to restate the original point, and "A" answered many of them by individual postings saying the same thing. Until the time when he said this: | You're | trying to give it meaning that was never intended, and by the "Could | a reasonable person, in good faith, really misunderstand our intention?" | test (which was one criterion for whether or not wording changes were | called for during evaluation of public-review comments), I would have | to say that the existing wording, taken in toto, is clear enough. This is the one posting by "A" in which the real question at issue -- whether the wording correctly reflects the Committee's intent -- seemed to me to be even addressed, and the thought that it might not do so is simply dismissed. Frankly, I consider that "Q" proved his case, and that this IS a bug in the pANS that slipped through the public reviews; but I concede that there's room for some doubt. Now I'd be happy to see an Interpretations Phase ruling that the intended meaning applies, but even if that doesn't happen, it's not the end of the world -- it's hard to see any reason why anyone would implement malloc() so as to make the first example fail anyway. What I am not happy about is that, after posting the above, "A" reverted to claiming that the pANS does not say what "Q" says it says, without proof, until the topic died. While the pANS references in this article are rather peripheral to my point, I'd better give them. These are for the December 7, 1988 version, the one intended to be final. The references for casts not being required, written in the form section/page/line, are the obscurely placed 3.3.4/ 46/28-29 combined with 3.3.16.1/54/3-5, 3.3.2.2/41/21-23, 3.3.2.2/42/10-11, 4.10.3.2/155/33, and 4.10.3.3/156/6. The references for the claim that there is a bug in the pANS are 4.10.3/155/13-15, 4.10.3.2/155/37, and 3.3.4/46/38; I won't repeat here the arguments about which words should be interpreted in what way. This article is crossposted to comp.lang.c and comp.std.c. I've put an invalid Followup-To line on it, to prevent followups from going to both groups by accident (what you do on purpose is your business), and because one should think twice about posting ANY metadiscussion -- like this article. I've been sitting still on this one for a few weeks, but I think it needs to be said. So here it is, and now I'll shut up on the topic. (If posting followups to a peripheral point, watch the Subject line as well as the Newsgroups.) This article is in the public domain. *Pun intended. **If it isn't still "proposed", I've missed something, and you can tell me so by email. The last I heard it was still being held up by a procedural appeal, which was redescribed on the net recently. -- Mark Brader "Yet again, I begged him to explain himself in plain Toronto English. This request always surprises him, as he utzoo!sq!msb is always under the extraordinary impression that msb@sq.com he has done so." -- Lynn & Jay, "Yes Minister"