🚀 go-pugleaf

In article <2131@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
>As much as we
>all wish that the standard were complete, concise, and correct, those
>of us who wrote it are only human and suffer from oversights,
>confusion, and mistaken beliefs from time to time.

I have enough first-hand experience with the same problems to feel much
sympathy for committee members who suffer them.  Nonetheless, when errors
are discovered, it is best if they be admitted and corrected.  (I have
not seen any evidence that Mr. Jones disagrees with this ideal.  Digital's
regulations prohibit me from reporting some other past observations.)

>In particular, when
>you know how something is supposed to work, it is very difficult to
>describe it in such complete detail that someone who is being
>intentionally perverse can't misunderstand it (try it some time). 

I have enough first-hand experience with this problem too, and again
express sympathy.

But there are also some cases where there is no misunderstanding at all,
and simply errors.  Sometimes the committee's intention is very clear,
but the legally accepted standard is worded in a manner to prohibit the
intended meaning.  This is not a matter of intentional perversity.
It is intentional careful reading.  I have often helped prove particular
cases, in hopes that they might be corrected some day.

I have often expressed personal wishes that errors could be corrected
through some procedure, as well as personal wishes that errors be
admitted and targeted for eventual corrections.

In comp.std.c, I have seen this kind of responsible posting by others
as well, more often than intentional perversity.

However, even intentional perversity has a right to be heard.  We often
have to resort to hypothesizing some perverse conforming implementation
in order to prove that some program will get an undesired result.  We
often have to resort to writing some perverse maybe-strictly-conforming
program in order to prove that some implementation fails to conform.

If I were an implementor, the best I could do would be to supply options
to choose between required meanings and intended meanings, with __STDC__
defaulting to not being defined in the latter case (but again, definable
by an explicit option).

>In general, if the standard implies something, then that is what it
>means, even if it doesn't come right out and say so.

That is fair.  But when the standard comes right out and says the opposite,
it needs to be fixed.  Computers do what we say, not what we mean.  We are
not computers, but when reading legal documents, we are still bound by
what the writers said, not by what they meant.  [Personal opinion only.]
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."