An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Asynchronous signal handling, for example, may cause objects to be modified in a manner unknown to the compiler. Without this type qualifier, unintended optimizations may occur. These optimizations may cause race conditions because a programmer may write code that prevents a race condition, yet the compiler is not aware of the programmer's data model and may modify the code during compilation to permit race conditions.
volatile keyword eliminates this confusion by imposing restrictions on access and caching. According to the C99 Rationale [C99 Rationale 2003],
No caching through this lvalue: each operation in the abstract semantics must be performed (that is, no caching assumptions may be made, because the location is not guaranteed to contain any previous value). In the absence of this qualifier, the contents of the designated location may be assumed to be unchanged except for possible aliasing.
Type qualifying objects as volatile does not guarantee synchronization between multiple threads, protect against simultaneous memory accesses, or, unless used to declare objects of type
sig_atomic_t, guarantee atomicity of accesses to the object. For restrictions specific to signal handlers, see SIG31-C. Do not access shared objects in signal handlers. However, type qualifying objects as volatile does ensure that a conforming compiler will not elide or reorder access to the object.
Noncompliant Code Example
In this noncompliant code example, the programmer is targeting a custom piece of hardware that controls an LED by writing values into a register bank. The register bank is memory mapped into the process such that writing to a specific memory location will actually place a value into a hardware register to be read by the LED controller. The programmer intends to turn the LED on by placing value 1 into the first register, and then turn the LED off later by placing the value 0 into the first register.
The compiler is free to optimize what it perceives as being a dead store to
bank by removing the first assignment to the variable. This would cause the LED to never be turned on in an optimized build.
In this compliant solution, the register bank's memory is qualified with the
volatile keyword, ensuring the compiler does not optimize access to the memory.
Failure to declare variables containing data that cannot be cached as volatile can result in unexpected runtime behavior resulting from compiler optimizations.
|LDRA tool suite|
|8 D||Partially implemented|
|Avoid unused values|
|Polyspace Bug Finder|
Variable never read after assignment
There shall be no dead code
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
|CERT C Secure Coding Standard||SIG31-C. Do not access shared objects in signal handlers|
|SEI CERT C++ Coding Standard||VOID DCL20-CPP. Use volatile for data that cannot be cached|
|MISRA C:2012||Rule 2.2 (required)|
|[C99 Rationale 2003]||Subclause 6.7.3, "Type Qualifiers"|