On Tue, Mar 5, 2013 at 4:27 AM, David Paterson <dnpaterson@xxxxxxxxx> wrote: > On 4 March 2013 23:40, Jeffrey Walton <noloader@xxxxxxxxx> wrote: >> >> ... >> I believe GCC's interpretation of the use for 'volatile' is memory >> mapped hardware. > > In addition to Jonathan's answer on the use of "volatile", it's worth adding > that it's not only used for memory mapped hardware. There are many other > uses, such as inter-thread communication, or indeed the example you > show below. A good discussion on the subject can be found at http://gcc.gnu.org/ml/gcc-help/2012-03/msg00239.html. The thread includes a discussion of Microsoft's and GCC's interpretation of the keyword. The interpretations were so different I wondered if it was 'implementation defined' in the standard. > ... > In this case, the use of "volatile" prevents an over-eager optimizer from > discarding this function completely, since it could assume that it does > nothing useful. I think the only way to do it properly with GCC is to put the function in its own source file and compile with -O0. Otherwise, I think you're playing with fire under GCC. OpenSSL uses other tricks to ensure the optimizer is tamed. Check out their OPENSSL_cleanse() function. Microsoft is a different story: you can use volatile, or even their SecureZeroMemory function [0], which is guaranteed to execute. I have not seen a problem (yet) with Clang/Clang++ or Intel ICC/ICPC. But I don't know their interpretation of the keyword. In the end, I think the C/C++ committee needs to supply another keyword to ensure program statements are never removed and executed in-situ with no side effects (perhaps 'pin'). They gave the compiler writer's 'restrict' so they could optimize. The security minded folks should get something too to ensure program correctness even when the optimizer is aggressive. Jeff [0] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366877%28v=vs.85%29.aspx
