Postings in comp.std.c and comp.lang.c

bdm659 at csc.anu.oz bdm659 at csc.anu.oz
Tue Dec 12 05:17:04 AEST 1989


[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 at sq.sq.com> msb at 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 at smoke.BRL.MIL>, gwyn at 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 at anucsd.oz  or  bdm659 at csc1.anu.oz.au
Terrorist: n. An individual who behaves like a government.



More information about the Comp.std.c mailing list