the "const" qualifier

Doug Gwyn gwyn at smoke.BRL.MIL
Tue Oct 17 15:28:58 AEST 1989


In article <3728 at solo10.cs.vu.nl> maart at cs.vu.nl (Maarten Litmaath) writes:
>Why?  (See below.)

The added complexity required to accurately specify what you might think
should be the rule for these other cases was not judged to be worth the
effort.  As it is, we were changing the wording about this stuff up to
practically the last minute before printing the final draft, because of
the difficulty in getting even the simpler case specified (a) right, and
(b) intelligibly.  The simpler case suffices for the Standard library
functions (str*() and mem*() in particular), and it was necessary to get
that right.

>\slight overloading of semantics for "const".  [...]
>Could you elaborate on this counter-intuitivity?

Given your propensity for grumbling about the standardization process,
I'm not sure I should.

In essence, a couple of years ago Tom Plum (I think it was) identified
the source of committee disputes about the meaning of type qualifiers
as due to there being three essentially orthogonal attributes involved,
not the two that we had been wrangling with ("const" and "volatile").
That allowed separating out the "noalias" meaning from "readonly", both
of which had been confused together in "const".  Subsequently, "const"
was in effect redefined to have the "readonly" meaning and "noalias"
was added as a separate type qualifier.  To make a long story short,
we had to retract "noalias" late in the review process, which left us
with the newly resurfaced problem of specifying the library facilities
such as str*() parameters in a way that had formerly been covered by
combining two type qualifiers ("const noalias"), one of which had just
vanished.  The best we could do under the circumstances is what is now
specified.  Many of us think "noalias", with the problems in its
specification straightened out, would have been a better solution, but
it wasn't politically feasible to reintroduce such a qualifier.

P.S.  This is my own recollection of the essence of what happened,
and you shouldn't take it as any sort of official X3J11 history!



More information about the Comp.std.c mailing list