Does extern "const" allocate storage?

[Dave Jones]

in article <3288 at haddock.ISC.COM>, karl at haddock.ISC.COM (Karl Heuer) says:
> 
> In article <136 at polygen.UUCP> pablo at polygen.uucp (Pablo Halpern) writes:

...

>>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
    

Why should my program know whether the "clock" variable is being
"modified by hardware", or modified by an interrupt-handler?  Why
shouldn't one implementation use a hardware register, and another
use an interrupt handler?  Without breaking any application code?

We used to make up jokes about "write-only" memory. But "read-only
volatile memory" is a pretty screwy idea too.   It's oxymoronic.

It's really a matter of information-hiding.  The consumer of the clock
variable needs to know that consumers are not to write to it. 
Consumers do not need to know the specifics of how the variable gets
written to.

I say, "const" should apply only to the file in which the declaration
occurs.


 -- Dave (If I could walk like lint, I wouldn't need the talcum) Jones