Page History

...

The volatile keyword eliminates this confusion by imposing restrictions on access and caching. According to the C99 Rationale [ISO/IEC 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, guarantees guarantee atomicity of accesses to the object. For restrictions specific to signal handlers, see SIG31-C. Do not access or modify 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 This noncompliant code example relies on the reception of a SIGINT signal to toggle a flag to terminate a loop. However, because interrupted is not declared volatile, the read from it in main() may be optimized away by the compiler despite the assignment to the variable in the signal handler, and the loop may never terminate. When compiled on GCC with the -O optimization flag, for example, the program fails to terminate even upon receiving a SIGINT, 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.

Code Block
bgColor #ffcccc#FFcccc lang c
#include <stddef.h> #include <signal<stdint.h> sig_atomicextern void get_register_bank(int32_t interrupted;**bank, /* bug: not declared volatile */ void sigint_handler(int signum) { interrupted = 1; /* assignment may not be visible in main() */ } int main(void) { signal(SIGINT, sigint_handlersize_t *num_registers); extern void while (!interrupted) { /* loop may never terminate */ /* do something */ } return 0; }

Compliant Solution

By adding the volatile qualifier to the variable declaration, interrupted is guaranteed to be accessed from its original address for every iteration of the while loop as well as from within the signal handler.

#include <signal.h>

volatile sig_atomic_t interrupted;

void sigint_handler(int signum) {
  interrupted = 1;
}

int main(void) {
  signal(SIGINT, sigint_handler);
  while (!interruptedexternal_wait(void);

void func(void) {
  int32_t bank[3];
  size_t num_regs = 3;

  get_register_bank((int32_t **)&bank, &num_regs);
  if (num_regs < 3) {
    /* doHandle somethingerror */
   }

  bank[0] = 1;
  external_wait();
  bank[0] return= 0;
}

The sig_atomic_t type is the integer type of an object that can be accessed as an atomic entity even in the presence of asynchronous interrupts. The type of sig_atomic_t is implementation-defined, though it provides some guarantees. Integer values ranging from SIG_ATOMIC_MIN through SIG_ATOMIC_MAX may be safely stored to a variable of the type. In addition, when sig_atomic_t is a signed integer type, SIG_ATOMIC_MIN must be no greater than -127 and SIG_ATOMIC_MAX no less than 127. Otherwise, SIG_ATOMIC_MIN must be 0 and SIG_ATOMIC_MAX must be no less than 255. The macros SIG_ATOMIC_MIN and SIG_ATOMIC_MAX are defined in the header <stdint.h>.

Noncompliant Code Example (Cast to volatile)

compiler is free to optimize what it perceives as being a dead store to bank[0] by removing the first assignment to the variable. This would cause the LED to never be turned on in an optimized build. 

Compliant Solution

In this compliant solution, the register bank's memory is qualified with the volatile keyword, ensuring the compiler does not optimize access to the memoryIn this noncompliant code example, the thread_func function runs in the context of multiple threads designed to communicate with one another via the global variable end_processing. The function attempts to prevent the compiler from optimizing away the while loop condition by casting the variable to volatile before accessing it. However, because end_processing is not declared volatile, the assignment to it in the body of the loop does not need to be flushed from a register into memory and consequently may not be visible when read despite the cast. As a result, the loop may never terminate.

extern int compute(void*);

static _Bool end_processing;

void* thread_func(void *arg) {
  while (0 == *(volatile _Bool*)&end_processing) {
    int status;
    status = compute(arg);
    if (status) {
#include <stddef.h>
#include <stdint.h>

extern void get_register_bank(volatile int32_t **bank,
                        /* notify other threads to end processingsize_t */
      end_processing = 1num_registers);
extern      break;
    }
  }
  return 0;
}

Compliant Solution

By adding the volatile qualifier to the variable declaration, end_processing is guaranteed to be read from and written to its original address for every iteration of the while loop.

extern int compute(void*);

static volatile _Bool end_processing;

void* thread_func(void *argvoid external_wait(void);

void func(void) {
  while (0 == end_processing) {volatile int32_t bank[3];
  size_t num_regs int= status3;

  get_register_bank((volatile  status = compute(argint32_t **)&bank, &num_regs);
  if (num_regs if< (status3) {
      /* notify other threads to end processing Handle error */
   }

   end_processingbank[0] = 1;
      breakexternal_wait();
    }
  }
  returnbank[0] = 0;
}

...

Risk Assessment

Failing to use the volatile qualifier Failure to declare variables containing data that cannot be cached as volatile can result in race conditions in asynchronous portions of the code, causing unexpected values to be stored and leading to possible data integrity violations.unexpected runtime behavior resulting from compiler optimizations.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

...

...

...

ISO/IEC 9899:1999 Section 6.7.3, "Type qualifiers"

ISO/IEC 9899:2011 Section 6.7.3, "Type qualifiers," and section 7.14, "Signal handling <signal.h>"

...

Bibliography

...

...

Bibliography

...

...

Image Modified Image Modified Image Modified