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

[Mark Brader]

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 at sq.com		 he has done so."	-- Lynn & Jay, "Yes Minister"