C volatile and restrict Keywords: Control Optimization and Pointer Aliasing

The volatile and restrict keywords solve very different problems in C. volatile tells the compiler that an object's value may change in ways that ordinary program flow does not reveal. restrict gives the compiler information about how pointers are used and can enable more aggressive optimization when its aliasing requirements are respected.

What Does volatile Mean?

The volatile qualifier tells the compiler that accesses to a volatile-qualified object are observable and must not simply be optimized away or freely combined as though the object could only change through the current program's ordinary execution.

Volatile is commonly encountered when accessing memory-mapped hardware registers, communicating with certain low-level system mechanisms, and sharing simple state with a signal handler.

Basic volatile Example

#include <stdio.h>

int main(void)
{
    volatile int status = 0;

    status = 1;
    printf("Status: %d\n", status);

    return 0;
}

Why Would a Compiler Optimize an Access?

Compilers normally assume that ordinary objects change only according to the rules visible in the program. This allows them to remove redundant reads or writes when doing so does not change observable behavior.

int value = 10;

int first = value;
int second = value;

For an ordinary object, the compiler may recognize that the second read cannot produce a different value unless something in the program changes value. A volatile object tells the compiler that each access may have externally observable consequences.

Volatile and Memory-Mapped Hardware

Embedded systems often expose hardware registers at fixed memory addresses. A volatile-qualified pointer can tell the compiler that reading or writing such a location must actually occur.

#include <stdint.h>

#define STATUS_REGISTER ((volatile uint32_t *)0x40000000u)

uint32_t readStatus(void)
{
    return *STATUS_REGISTER;
}

The address and register definition in this example are platform-specific. The important concept is that the compiler must treat accesses to the volatile object as significant.

Volatile Does Not Mean Atomic

A volatile variable is not automatically atomic. If multiple threads access shared data, volatile does not provide the synchronization needed to prevent data races.

volatile int sharedValue;

/* volatile does not make concurrent updates safe. */

Volatile Does Not Mean Thread-Safe

For communication between threads, use the C11 atomic facilities or an appropriate synchronization mechanism. volatile should not be used as a replacement for atomic operations, mutexes, or memory-ordering primitives.

Volatile and Signal Handlers

A common C pattern is using volatile sig_atomic_t for a simple flag modified by a signal handler.

#include <signal.h>
#include <stdio.h>

static volatile sig_atomic_t stop = 0;

static void handleSignal(int signalNumber)
{
    (void)signalNumber;
    stop = 1;
}

int main(void)
{
    signal(SIGINT, handleSignal);

    while (!stop)
    {
        /* Main program work. */
    }

    printf("Stopping.\n");

    return 0;
}

sig_atomic_t is important here because C provides it specifically for objects that can be accessed atomically with respect to signal handling. volatile helps ensure the compiler does not treat accesses to the flag as ordinary invariant data.

Volatile and const

const and volatile can be used together. const prevents modification through a particular access path, while volatile indicates that the object's value may change independently of ordinary program flow.

const volatile int hardwareStatus = 0;

This combination can be useful for a hardware status register that software may read but should not write.

Volatile Pointer vs Pointer to Volatile

The location of volatile in a declaration matters.

volatile int *p;
int *volatile p2;

What Does restrict Mean?

The restrict qualifier is primarily an optimization aid for pointer-based code. It tells the compiler that, for a particular execution of a block, an object accessed through a restrict-qualified pointer is accessed in the relevant way through that pointer rather than through an unrelated pointer.

The promise is a programmer responsibility. If the restrictions required by restrict are violated, the resulting program can have undefined behavior.

A Simple restrict Example

void addArrays(size_t n,
               int *restrict destination,
               const int *restrict left,
               const int *restrict right)
{
    for (size_t i = 0; i < n; i++)
    {
        destination[i] = left[i] + right[i];
    }
}

The restrict qualifiers communicate that the arrays accessed through these pointers are not overlapping in a way that violates the restrict contract.

Why restrict Can Improve Optimization

Without aliasing information, a compiler may need to assume that writing through one pointer could change data observed through another pointer. restrict can remove that uncertainty when the programmer guarantees the required non-aliasing relationship.

An Aliasing Example

void copyValues(size_t n,
                int *restrict destination,
                const int *restrict source)
{
    for (size_t i = 0; i < n; i++)
    {
        destination[i] = source[i];
    }
}

This function is appropriate when destination and source refer to separate regions of storage. If overlapping regions need to be supported, a restrict-qualified interface may not be appropriate.

restrict and memcpy

Standard library functions such as memcpy are specified with restrict-qualified pointer parameters because memcpy requires the source and destination objects not to overlap. For overlapping regions, memmove is the appropriate function.

#include <string.h>

memcpy(destination, source, size);

/* Use memmove when regions may overlap. */
memmove(destination, source, size);

A restrict Violation

The following pattern can violate the assumptions associated with restrict because the same object is accessed through multiple restrict-qualified pointer paths.

void update(int *restrict a, int *restrict b)
{
    *a += 1;
    *b += 1;
}

int value = 10;

/* Do not do this when the restrict contract is violated. */
update(&value, &value);

The exact rules for restrict are detailed in the C standard and are more subtle than simply saying that two restrict pointers can never have the same value. The key practical rule is to use restrict only when you can establish the required access relationship.

restrict Is Not a Runtime Check

The compiler generally does not insert a runtime check to determine whether a restrict promise is true. restrict is a language-level contract that gives the implementation optimization freedom.

Combining const and restrict

A common and useful combination is a pointer to read-only data that also carries a restrict promise.

void process(size_t n,
             const float *restrict input,
             float *restrict output)
{
    for (size_t i = 0; i < n; i++)
    {
        output[i] = input[i] * 2.0f;
    }
}

Here const says the function will not modify the input through input, while restrict communicates the intended non-overlapping access relationship.

volatile vs restrict

They Solve Different Problems

volatile tells the compiler not to treat accesses to an object as ordinary removable or freely optimizable accesses. restrict tells the compiler about a programmer-guaranteed relationship between pointer-based accesses. One does not replace the other.

volatile and Compiler Reordering

volatile does not turn an object into a full memory barrier. It specifies requirements concerning accesses to volatile objects, but it does not by itself establish general synchronization or ordering between threads.

restrict and Data Races

restrict also does not provide synchronization. It describes aliasing assumptions for a particular execution context; it does not make concurrent access to shared objects safe.

When Should You Use volatile?

• Memory-mapped hardware registers
• Certain low-level device interfaces
• Simple signal-handler communication using volatile sig_atomic_t
• Special implementation-defined environments where external changes must be observed

When Should You Use restrict?

• Functions operating on separate input and output buffers
• Numerical or array-processing routines where non-aliasing is guaranteed
• Performance-sensitive pointer-based APIs where aliasing information can help optimization
• Interfaces modeled after standard memory-processing functions with appropriate non-overlap requirements

Common Mistakes

• Using volatile as a substitute for thread synchronization
• Assuming volatile makes operations atomic
• Using volatile simply to prevent compiler optimization
• Adding restrict without being certain its aliasing requirements are satisfied
• Assuming restrict performs a runtime overlap check
• Using restrict on functions that are intentionally designed to support overlapping buffers
• Assuming volatile and restrict provide the same type of optimization control

Best Practices

• Use volatile for genuinely externally changing or special objects, not as a general optimization switch
• Use atomic types and synchronization primitives for inter-thread communication
• Keep signal handlers minimal and use volatile sig_atomic_t for simple signal flags
• Use restrict only when the required aliasing contract is genuinely guaranteed
• Document non-aliasing assumptions in performance-critical APIs
• Measure performance before adding restrict solely for optimization reasons
• Prefer clear and correct code over speculative qualifier usage

Quick Reference

Practice Exercises

• Create a volatile variable and inspect how it differs conceptually from an ordinary variable
• Write a SIGINT handler using volatile sig_atomic_t
• Create a function using restrict-qualified input and output arrays
• Experiment with a function that supports overlapping buffers and determine why restrict may be inappropriate
• Compare memcpy and memmove for overlapping regions
• Use const and restrict together in an array-processing function
• Identify places in a C program where volatile is being incorrectly used as a threading mechanism

Conclusion

volatile and restrict are powerful C qualifiers, but they address very different concerns. volatile is about how accesses to certain objects must be treated, while restrict communicates pointer aliasing assumptions that can enable optimization. Used correctly, both can be valuable in low-level and performance-sensitive C code. Used incorrectly, especially for synchronization or unsupported aliasing assumptions, they can create subtle bugs.