The C memory model describes program state through objects, storage, values, representations, and pointers rather than fixed physical addresses. Applying & to an object produces an address that can be used through a pointer to inspect or modify execution state. That address may correspond to virtual memory, a file, or an I/O port; portable C does not require a particular physical arrangement. section 12.0 section 12.3
Figure 12.1 The different levels of the value-memory model for an int32_t. Example of a platform that maps this type to a 32-bit signed int and uses a little-endian object representation.
A layered diagram traces an int32_t from value and object representation through binary representation, including a 32-bit signed mapping and little-endian layout. section 12.0
The model separates several related concerns:
- Physical memory is hidden behind virtual memory, giving processes a portable address space and protecting memory they do not own. section 12.0
- Each object consists of bytes called its object representation; unions can overlay different types on that representation. section 12.0 section 12.8
- Pointer types are distinct when their base types differ, and, except for character types, only pointers with the same base type may alias. section 12.0 section 12.3
- Storage may begin as uninterpreted bytes and acquire a type when a value is stored; storage duration, lifetime, visibility, initialization, and alignment then constrain access. section 13.0 section 12.8
Aliasing changes what a function may return
Given `double blub(double const* a, double* b)`, calling the function with distinct addresses leaves `*a` unchanged, but calling `blub(&c, &c)` lets the assignment through `b` change what `a` observes. The function may therefore return either the original value or the modified value. With `size_t const* a` and `double* b`, the different base types rule out that aliasing case, so the return must be the original value. section 12.3
