Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!zephyr.ens.tek.com!tektronix!sequent!ccssrv!perry
From: perry@ccssrv.UUCP (Perry Hutchison)
Newsgroups: comp.std.c
Subject: Re: the "const" qualifier
Message-ID: <742@ccssrv.UUCP>
Date: 18 Oct 89 23:02:08 GMT
References: <12239@cit-vax.Caltech.Edu> <11301@smoke.BRL.MIL> <3728@solo10.cs.vu.nl> <11320@smoke.BRL.MIL>
Reply-To: perry@ccssrv.UUCP (Perry Hutchison)
Organization: Control-C Software, Inc., Beaverton, OR
Lines: 23

In article <11320@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:

+ 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 ...
+ That allowed separating out the "noalias" meaning from "readonly", both
+ of which had been confused together in "const" ... "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 ...
+ 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.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In other words, a _technically_ defective hack was put in the standard at
the last minute, to satisfy someone's _political_ agenda.

It sounds to me like the current "proposed standard" deserves to be voted
down and sent back to committee to have this mess (and any other problems
which may have surfaced) cleaned up.