Question

Here’s the problem: your program temporarily uses some sensitive data and wants to erase it when it’s no longer needed. Using std::fill() on itself won’t always help – the compiler might decide that the memory block is not accessed later, so erasing it is a waste of time and eliminate erasing code.

User ybungalobill suggests using volatile keyword:

{
  char buffer[size];
  //obtain and use password
  std::fill_n( (volatile char*)buffer, size, 0);
}

The intent is that upon seeing the volatile keyword the compiler will not try to eliminate the call to std::fill_n().

Will volatile keyword always prevent the compiler from such memory modifying code elimination?

Answer 1

The compiler is free to optimize your code out because buffer is not a volatile object.

The Standard only requires a compiler to strictly adhere to semantics for volatile objects. Here is what C++03 says

The least requirements on a conforming implementation are:

• At sequence points, volatile objects are stable in the sense that previous evaluations are complete and
  subsequent evaluations have not yet occurred.
  […]

and

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

In your example, what you have are reads and writes using volatile lvalues to non-volatile objects. C++0x removed the second text I quoted above, because it’s redundant. C++0x just says

The least requirements on a conforming implementation are:

• Access to volatile objects are evaluated strictly according to the rules of the abstract machine.[…]

These collectively are referred to as the observable behavior of the program.

While one may argue that “volatile data” could maybe mean “data accessed by volatile lvalues”, which would still be quite a stretch, the C++0x wording removed all doubts about your code and clearly allows implementations to optimize it away.

But as people pointed out to me, It probably does not matter in practice. A compiler that optimizes such a thing will most probably go against the programmers intention (why would someone have a pointer to volatile otherwise) and so would probably contain a bug. Still, I have experienced compiler vendors that cited these paragraphs when they were faced with bugreports about their over-aggressive optimizations. In the end, volatile is inherent platform specific and you are supposed to double check the result anyway.