Re: Volatile qualification on pointer and data

[David Brown <david at westcontrol dot com>]

On 24/09/2011 17:09, John Regehr wrote:
> > What can't make sense is a /static/ "volatile const" which is
> > /defined/ locally, rather than just declared.
>
> The code in question sounds well-defined (but probably poor style) to me.
>
> It is never OK to access a qualified object through an unqualified
> pointer, but my understanding is that accessing an unqualified object
> through a qualified pointer is well-defined and that the usual qualifier
> rules apply to that access.

That is correct, and it is best to view the qualifiers as qualifying the 
access to the object, rather than the object itself.  Qualifying the 
object just states the minimum qualifiers needed to legally access it.

> David, is your "can't make sense" backed up by a standard? There is no
> "lying to the compiler", there is only conforming and non-conforming code.

I don't think the standard has any restrictions on the combinations of 
qualifiers you can have on an object - thus it is legal C to have a 
"static volatile const" object, or to access a "static const" through a 
"volatile" access.  But being legal C does not imply that it makes 
logical sense!

Is it "lying to the compiler"?  Perhaps not, but it is certainly saying 
two different things at the same time - they cannot both make sense, and 
I think the compiler is free to implement whichever of the conflicting 
ideas it wants.

However, I am far from sure here - I am raising the question, not 
answering it.  And while I think the compiler should be allowed to 
generate the optimised code of 4.6 (i.e., the change is not a bug IMHO), 
I fully understand the idea of generating the older, slower, but 
definitely correct code of 4.5.

I am still trying to imagine a real-world use-case for declaring an 
object "static const" and later accessing it as "volatile".

mvh.,

David