Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Does extern "const" allocate storage?
Message-ID: <7487@brl-smoke.ARPA>
Date: 20 Mar 88 03:12:03 GMT
References: <7712@apple.Apple.Com> <1988Mar17.175448.521@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 27

In article <1988Mar17.175448.521@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>The idea is fine, but nobody really understands the implications well enough
>to be sure it's being done right.  X3J11 has violated its own rules about
>not adopting untried and poorly-understood inventions.

The first sentence is erroneous; several people fully understand the
issue, its implications for the implementation, and its implications
for the programmer.  (Their evaluations of the desirability of the
feature vary widely, however.)  I don't claim to be one of them, but
I think I understand the issue in general.

There are known technical errors in the current wording that have to
be fixed before the final standard if "noalias" is to remain; these
have nothing to do with the desirability of the feature, though.

As to your second sentence, there is some merit to it.  Many committee
members were uneasy at introducing such a major invention at this late
date, but it was done to resolve an issue that had remained unsolved
for several meetings.  For a while it looked like there would never be
a solution that enough people would accept; "noalias" was by far the
most generally acceptable proposal for dealing with the aliasing vs.
optimization issue.  You and I probably would agree what the solution
"should" have been (namely, to simply disallow unsafe optimization),
but there were many people who didn't want to accept that solution.

The above is anecdotal and should not be considered official X3J11
history.