msb@sq.sq.com (Mark Brader) (12/05/89)
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"
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/05/89)
In article <1989Dec4.193436.4613@sq.sq.com> msb@sq.com (Mark Brader) writes: >But "A" continued to maintain that the pANS "does not require that" [meaning, saving the original void* representation from malloc() to feed to free() instead of a pointer that has undergone a series of type conversions]. You might as well use my name instead of"A". The reason I maintained that is because it's true. The C Standard permits a suitably aligned pointer (which the result of malloc() definitely is) to be converted to point to another type and back and still compare equal to the original pointer. It also permits a variety of pointer arithmetic to be applied. Any reasonable interpretation of the function of free() would have to take the "matching" constraint as meaning "pointer compares equal", simply because there is no ground for introducing an extraneous concept such as blue paint, tag bits, etc. in this context. That is not to say that under some content-free interpretation of logic, one might not be permitted to do so; however, it would be unreasonable, just as any of a number of other things simply not contemplated by the Standard would be unreasonable. (For example, every getchar() could as a side-effect delete all accessible files, for after all the Standard doesn't constrain this either!) >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. I fully understood the putative "technical" point "Q" raised all along, and as I said I believe what the Standard requires here is quite clear. However, I do not believe (as you also indicated) that "Q" actually failed to understand what the intention of the Standard was in this context. Rather, it seems to me he is trying to show how "clever" he is by picking nits and blowing them out of proportion. Other X3J11 members during meetings made almost identical observations about some of the other comments received during the public review process. If there were real problems in the proposed Standard that would have hurt its practical utility, X3J11 wanted to hear about them. Silly arguments over how many ways there are to misinterpret the intent of the Standard if one tries hard enough to do so are not helpful. >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. Would you believe that one of the nit-pickers is still nagging me about this, and claims that he actually wants to implement the ridiculously restrictive scheme. I hope he does so and finds out how many of his customers think he's being "reasonable". >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. Because I and several others had already made all the technical arguments about pointer conversion, equality testing, etc. and it is not my habit to repeat details to those who ignored them the first time around. This is NOT a technical issue, despite its appearance. It is an issue of whether the Standard needs to (necessarily, futilely) attempt to anticipate all possible misinterpretations, no matter how far-fetched and no matter how willfully stubborn the misinterpreter is, or whether it is sufficient for it to address the issues required by men of good faith. I claim the latter.
bdm659@csc.anu.oz (12/12/89)
In article <11742@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <1989Dec4.193436.4613@sq.sq.com> msb@sq.com (Mark Brader) writes: > > You might as well use my name instead of"A". > And I'm Q. See comp.std.c for my response. Brendan McKay.