Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!csc!bdm659 From: bdm659@csc.anu.oz Newsgroups: comp.std.c Subject: Re: Postings in comp.std.c and comp.lang.c Message-ID: <1120.2583ef20@csc.anu.oz> Date: 11 Dec 89 18:17:04 GMT References: <7130@ficc.uu.net> <11363@smoke.BRL.MIL> <1989Dec4.193436.4613@sq.sq.com> <11742@smoke.BRL.MIL> Followup-To: comp.std.c Organization: Computer Services, Australian National University Lines: 95 [Quotes from earlier articles are subsetted at the sentence level. See the originals for full context. "B>" means "Mark Brader", "A>" means "Doug Gwyn", a.k.a. "A".] In article <1989Dec4.193436.4613@sq.sq.com> msb@sq.com (Mark Brader) writes: B> As an instance of how NOT to conduct a discussion, I point to the B> recent one about a "common malloc/free practice". I avoid naming names B> here because I am criticizing the writings and not the writers, and B> it's possible that I am remembering some details wrongly, in which case B> you may treat this as a fictitious example of how not... Fair enough, though the true history is instructive too. B> The original poster (say "Q") said something of this form: "It is common B> in existing code to do the following, but I cannot see anything in the B> pANS to say that it is guaranteed to work. Is it?" G'day. Q here. B> Unfortunately, "Q" posted the question to comp.lang.c as well as comp.std.c, Yes, a mistake probably. B> and (I think) did not state very clearly what the actual point at issue was. B> This led to a flock of followups that ignored the fact that the question B> was about the pANS, justifying the first version of the code in terms of B> manuals for existing releases, and the like. B> B> There were several rounds of confused postings and "Q" eventually said B> that he never thought the Committee intended to require code of the form B> of the second example above; he was only pointing out what he thought was a B> bug in the pANS. How much simpler if he had said that in the first place! Well, I put "proposed ANSI C standard" in the title. The article mentions the "Standard" several more times, and contains a quote with section number. I also said "No doubt this problem was unintentional." and "Note that I'm not claiming the Standard is broken, only that the writers of the standard have accidentally ruled out a common coding practice." Alas, it wasn't enough. Only a few respondents understood the point, though "A" was one of those who did (which doesn't imply that I agree with him). In article <11742@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: A> You might as well use my name instead of "A". And miss getting to call you "A"? A> The reason I maintained that is because it's true. The C Standard A> permits a suitably aligned pointer (which the result of malloc() A> definitely is) to be converted to point to another type and back A> and still compare equal to the original pointer. The alignment requirements for this double cast to return the original value are set out clearly enough in 3.3.4. In order to apply them to the malloc return value, you have to decide what "suitably aligned" means in 4.10.3. You took it to mean that the space allocated by malloc() has the alignment requirements of any type of object. I took it to mean what the sentence actually says it means, namely that the alignment is sufficient that the value can be cast to a pointer to any type of object and used to access such an object in the space allocated. My hypothetical implementation was intended to demonstrate that my interpretation didn't violate any other rules. I think I succeeded. I believe my interpretation is much closer to the actual meanings of the words than yours is. However, it breaks the most common usage of malloc/free and so probably doesn't correspond to the committee's intention. This is all I've ever claimed to be arguing. A> I fully understood the putative "technical" point "Q" raised all along, A> and as I said I believe what the Standard requires here is quite clear. A> However, I do not believe (as you also indicated) that "Q" actually A> failed to understand what the intention of the Standard was in this A> context. Rather, it seems to me he is trying to show how "clever" he A> is by picking nits and blowing them out of proportion. It's just amazing how many people know more about the inside of my head than I do. See the quotes from my original posting that I've given above. I haven't changed my position on the matter. I DID understand the intention of the Standard, but I also believed that the words and the intention differ. Irrespective of whether I was right or wrong, I was perfectly justified in drawing attention to these concerns. A> This is NOT a technical issue, despite its appearance. It is an issue A> of whether the Standard needs to (necessarily, futilely) attempt to A> anticipate all possible misinterpretations, no matter how far-fetched A> and no matter how willfully stubborn the misinterpreter is, or whether A> it is sufficient for it to address the issues required by men of good A> faith. I claim the latter. Since all my postings were in good faith, this can't be aimed at me, can it? =============================================================== Brendan "Q" McKay. bdm@anucsd.oz or bdm659@csc1.anu.oz.au Terrorist: n. An individual who behaves like a government.