Does extern "const" allocate storage?

[Karl Heuer]

In article <136 at polygen.UUCP> pablo at polygen.uucp (Pablo Halpern) writes:
>From article <3117 at haddock.ISC.COM>, by karl at haddock.ISC.COM (Karl Heuer):
>>An object which is declared const but not volatile can never be modified by
>>a correct program.  A conforming implementation is allowed to take advantage
>>of this knowledge, by putting it in read-only memory and/or by inlining it.
>
>I disagree.  An object that is declared const but not volatile can not
>be modified within the scope in which the declaration holds.  Nowhere
>does the standard say that such an object is "really constant."

Footnote 50 certainly implies it.  If the body of the standard doesn't say
that modifying a const object through a non-const handle is undefined, I'm
sure the Committee would like to correct the oversight.

(Note: I'm talking about actual objects declared const.  Your statement is
true for a dereferenced pointer-to-const.)

>In the standard, a clock register is used as an example of a volatile const.
>The declaration looked something like:
>	extern const volatile int clock;
>The meaning of this is explaned that the clock register may not be written to
>by the program and that if it is read once, the value may be different if it
>is read again.  The question is, doesn't this imply that somewhere there is a
>function that might [modify it through a non-const handle]

No, the dpANS said that this may be "modifiable by hardware".  A memory-mapped
address could be so declared.  (Presumably the linker will bind the unresolved
extern to the appropriate magic location.)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint