Does C++ Standard description of indirection operator guarantee memory writes are not optimized away?

Question

This is basically a continuation of this question. So far it looks like that if I have a function like this:

void SecureZeroMemory( void* ptr, size_t cnt )
{
   volatile char *vptr = (volatile char *)ptr;
   while (cnt) {
       *vptr = 0;
       vptr++;
       cnt--;
   }
}

and call it like this:

{
    char buffer[size];
    SecureZeroMemory( buffer, size );
}

then since buffer is not declared volatile it doesn't matter that a pointer to volatile is used - the data itself is not volatile, so write to the variable do not constitute observable behavior (1.9/6) and the compiler is allowed to optimize them away.

However recently I've come across a statement that it's only the pointer declaration that matters. Specifically C++03 5.3.1/1 describes indirection (*) like this:

The unary * operator performs indirection [...] If the type of the expression is “pointer to T,” the type of the result is “T.”

So the claim is that because of using indirection on a volatile char* we get volatile char and writes to those do constitute observable behavior and it no longer matters how the actual data is declared.

Does the C++03 5.3.1/1 description of indirection really guarantee that overwriting memory using a volatile T* pointer as in the sample above constitute observable behavior and is disallowed to be optimized away?

Answer 1

I'm pretty sure all that "new" quote adds is that *vptr is an lvalue expression with type volatile char.

The type of the lvalue doesn't affect the type of the object to which that lvalue expression refers, for the same reason that a pointer-to-const that points at a non-const object doesn't somehow make the object const. So the original analysis isn't affected this quote -- the object still doesn't have volatile-qualified type.

In normal parlance we'd say that the type of *vptr is volatile char &, but 5/5 says, "If an expression initially has the type “reference to T” the type is adjusted to T prior to any further analysis". That's the reason why *vptr is said to have type volatile char, not volatile char & -- before analysing any expression you remove the reference from the type, even if it's an lvalue.

[Edit: my answer used to have some text about cv-qualifications being insignificant for non-object values of integer type. It was true (lvalue-to-rvalue conversions of non-class types discard cv-qualifiers, 4.1/1) but irrelevant (I mistakenly thought that because the text you quoted mentioned a non-reference type it was talking about the type after this conversion)]

Answer 2

It's an interesting question. I think the intent of the standard was that this should work. On reading the standard (C++03, §1.9/6,7) however:

The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions.

Accessing an object designated by a volatile lvalue, modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

The difference in wording in the two paragraphs would seem to be significant: the "observable behavior" is the sequence of reads and writes volatile data. In your case, buffer is not volatile data, so the compiler is, presumably, free to optimize the accesses away. I don't think that this is the intent, but that seems to be what it says.

In your case, the optimization would be particularly simple, since the conversion to volatile occurs in the function itself. The compiler can easily determine that vptr doesn't point to data that is actually volatile. If you change the parameter type to void volatile*, then the compiler would have to see both the call site and the function at the same time in order to safely do the optimization.

And finally, regardless of what the standard says, compilers have their own interpretations of volatile. In practice, most, if not all compilers, will assume that you are using volatile for a reason, and will generate the machine instructions to do the writes. (In practice, that is all that they will do, which means that the order that the writes become visible outside of the thread the code in which the thread is running remains undefined. This isn't a problem for your use, but it is for a lot of other uses.)