Xref: utzoo comp.std.c:2230 comp.lang.c:24251
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Postings in comp.std.c and comp.lang.c
Message-ID: <11742@smoke.BRL.MIL>
Date: 5 Dec 89 06:34:00 GMT
References: <7130@ficc.uu.net> <11363@smoke.BRL.MIL> <1989Dec4.193436.4613@sq.sq.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Followup-To: comp.std.c
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 73

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.