Ways to break your systems code using volatile (2010)
There are gaping omissions in this article.<p>There is a need for volatile in portable C programming, in two circumstances:<p>1. When an asynchronous signal handler modifies a variable that is inspected by the interrupted mainline code (e.g. to set a flag indicating that the signal went off), that variable must be of type &quot;volatile sig_atomic_t&quot;. (The article points to some outside discussion by Hans Boehm about this in relation to Unix, but it&#x27;s not just for Unix; it&#x27;s in ISO C.)<p>2. When a function, after saving a context with setjmp(), modifies automatic local variables, and then the context is restored with longjmp(), those variables must be declared volatile, or else they will not reliably have the correct values. (E.g. the longjmp may or may not restore the values which they had at setjmp time, or do it for some of those variables but not others.)<p>No matter how a C compiler treats volatile, in order to be ISO C conforming, if the program correctly uses volatile in the above situations, it must somehow work. Even if it is useless for anything else: threads, hardware, ...<p><pre><code>  {
    volatile int i = 0;

    if (setjmp(jmp_buf) == 0) {
      i++;
      longjmp(jmp_buf, 1);
    } else {
      printf(&quot;i == %d\n&quot;, i);
    }
  }
</code></pre>
Here, the printf should produce i == 1, which is not required if the <i>volatile</i> is removed.<p>For instance, if i is located in a machine register, and setjmp&#x2F;longjmp work by saving and restoring registers (or just some registers, including that one), the longjmp operation will restore the value that existed in the register at the time setjmp was called, which is zero.<p>If that&#x27;s a problem in a given compiler, even if it has a garbage implementation of volatile, it has to pay attention to the fact that volatile is being used in setjmp code.