-=> John Gardeniers wrote to Bill Birrell <=-

 JG> Interesting wording. As far as I'm concerned ALL constants are 
 JG> non-volatile. They can be nothing else. If it's volatile it can
 JG> hardly be thought of as a constant, can it?

While "const volatile" is non-intuitive, I think it's already been
explained pretty well here. In short: a variable which can't be altered by
the program, but CAN be altered by some other process.

Example: a read-only hardware port mapped to memory. Declaring it as
"const" tells the compiler "don't let the program try to write to this
location". Declaring it as "volatile" says "don't try
to optimize multiple
accesses away; fetch the value each time". These are compatible.

 JG> Many people seem to think that the ability to create a pointer to
 JG> something is "proof" that memory is set aside for it. This is of
 JG> course nonsense as a pointer merely points to a memory address, real
 JG> or otherwise. There is no rule to say that such an address must be
 JG> within an area reserved for variable storage.

True. But I don't know that anyone has contended this.

Or, from another point of view: any memory that such an address refers to
is "an area reserved for variable storage", by definition. :-)

I know that many compilers puts consts into the code segment, rather than
the data segment (on systems where this distinction is meaningful).

 JG> Indeed, there is nothing to prevent us creating pointers to
 JG> non-existing memory addresses.

But they had better be existing once you try to dereference them. And
that's why the compiler can't optimize the storage away.

 const int foo = 5;
 const int *bar, *baz;

 bar = &foo;
 baz = bar;

 printf("%d\n", *baz);

I'd like to see the compiler that could optimize all the pointers out of
that, or something more complex.

... Famous Last Words: "Don't worry, I can handle it"
--- MultiMail/Linux v0.19