4 ms·
Ok, that's quite some language-lawyering going on here ;-), and while I enjoy it, I'm completely aware of the fact that in practice the behavior of actual imple
by cnvogel 12y ago
Ok, that's quite some language-lawyering going on here ;-), and while I enjoy it, I'm completely aware of the fact that in practice the behavior of actual implementation (in software, compilers, operating systems) always trumps theoretic considerations.
That being said...
§6.5.3.1/4 The unary * operator denotes indirection. (...) the result is an lvalue designating the object.
So, I believe that there will be no difference in access to something declared as
volatile X v;
v = ...;
and
X v;
*((volatile X*)&v) = ...;
if the access to v will always be performed through such a cast, as ((volatile..)) will always denote the same "volatile" X object stored in v, independent of the fact that storage to the volatile X object is allocated in a "nonvolatile" X object.
- cperciva 12y agoIn practice most compilers respect the volatile keyword on a pointer target type. But if you want to conform to the standard you need to look at what the standard says, not merely how it's commonly implemented. §6.5.3.1/4 The unary * operator denotes indirection. (...) the result is an lvalue designating the object. Yes, but calling the sky green doesn't make it so. Dereferencing a pointer to an object yields that object, and the object is volatile or not depending on whether it was declared as volatile; whether you say that it's volatile before you dereference the pointer is irrelevant. (That is, irrelevant to the requirements of the standard; it's very relevant to most compilers, because it's usually impossible to prove whether the object ultimately being accessed is volatile or not.)