Re: Volatile qualification on pointer and data

[David Brown <david.brown@hesbynett.no>]

On 25/09/11 16:16, Andreas Schwab wrote:
> David Brown<david@westcontrol.com>  writes:
>
>> There is a big difference between defining an object as "const", and
>> merely declaring it as const or accessing it as const.  When you access it
>> as const, you are saying "/I/ won't change the object with this access".
>> When you declare an object as const (such as an extern object), you are
>> saying "/I/ won't change this object".  When you /define/ an object as
>> const, as you do with a "static const", you are saying "this object is
>> constant.  It will never change value - you (the toolchain) can safely
>> place it in read-only memory that cannot ever change value".
>
> You are interpreting too much into const here.  The C standard says in
> footnote 112: "The implementation may place a const object that is not
> volatile in a read-only region of storage."  Note the use of "not
> volatile".  But in any case this is not part of the C standard: it's
> only a footnote.
>

I stand corrected on that point - thanks.

>> And then you make it volatile, telling the compiler "this object might
>> change unexpectedly, or use values written to it unexpectedly".
>>
>> If someone could explain to me how this could have real-world usage, I
>> think it would be easier for me (and others) to be sure of what it really
>> means.
>
> It's an object that is never written to, but may change unexpectedly.
>

Again, I can see that "volatile const" is useful for declaring external 
objects (or accesses to objects), but not when the address of the object 
is allocated by the toolchain (as is the case here with a "static const 
volatile".

The only scenario I have heard where this might be useful is for 
debugging - making what is normally a "static const" volatile so that 
it's value can be changed with a debugger.  Personally, I think that in 
such cases you would be better removing the "const" when you add the 
"volatile".