A proposed name for the storage behind a C object
N2328 proposes storage instance as a term for the region reserved by an allocation or object definition. The distinction separates the storage's lifetime from an address that can later be reused.
An address can remain numerically familiar after the storage it once identified has ceased to exist. C's terminology needs to describe that distinction without using the same word for the allocation, a typed object and its address. Jens Gustedt's N2328 proposes the term storage instance for the maximal region of storage created by an allocation or an object definition. The WG14 document log lists the paper on December 10.
The paper is dated December 9 and describes itself as clarification of the existing model. It explicitly disclaims adding new features. Its purpose is to give the standard a consistent name for something that existing wording variously calls space, memory, storage or an object. The proposed term also carries a temporal distinction through the word instance.
C's storage model matters to me because understanding its lifetime boundaries is necessary for writing it correctly. A vocabulary change can help when it separates concepts that a pointer value alone cannot explain. It remains a proposal, though, and should be evaluated by the distinctions its wording actually makes.
Storage and typed objects are different concepts
Gustedt identifies a problem with using object as the general name for an allocation. Objects can themselves contain subobjects, such as structure members. The maximal region obtained from an allocation is therefore a different concept from each object represented within it.
The proposal also separates typed interpretation from the storage facility. An allocated region does not acquire a declared type merely because the allocator returned it. The paper argues that the standard should distinguish the storage that represents an object from the object understood by the abstract machine. That distinction helps avoid treating every mention of allocated storage as though it named one declared object.
The proposed definition covers storage created by a definition as well as storage obtained through allocation functions. That breadth is intentional. Storage duration already applies to static, thread, automatic and allocated cases. A common term can describe the reserved region without requiring a separate informal noun each time the standard discusses one of those cases.
N2328 also notes that some objects have no known address, citing register variables. Its proposed definition therefore does not require every storage instance to have an address. The concept names the storage reserved in the execution model, not only a region that application code can identify through a usable pointer.
An instance has limits in time
The temporal part of the term is important because the same address can identify different instances during execution. Reentering a block can create a new automatic object. Allocation and deallocation can also cause an address to be reused. The paper argues that these are distinct instances even if a later address resembles an earlier one.
Its lifetime wording makes a reserved storage instance the guarantee associated with an object's existence. The proposal retains the rule that referring to an object outside its lifetime has undefined behavior. It also retains the indeterminate status of a pointer when the object it identifies, or points just past, reaches the end of its lifetime.
The implication is specific. A later allocation at a reused address does not make the earlier object's lifetime continue through the intervening deallocation. The temporal identity of the reserved storage must remain part of the explanation. An address describes location, while the instance describes a region created and destroyed during a particular part of execution.
I find that distinction more useful than explanations that describe lifetime only through visible addresses. Code review needs a way to discuss when a pointer's relationship to an object ends. Naming the reserved instance gives that discussion a subject without implying that a familiar address preserves the relationship.
The edit reaches representation and library wording
N2328 proposes two main additions. One defines storage instance with notes about creation, placement and accessibility. The other places the concept in the object-representation section and describes how most such storage can be viewed as an array of unsigned characters.
The remaining changes include terminology replacements and more extensive reformulations. Gustedt identifies lifetime paragraphs, flexible array member extent and memory-management functions among the affected areas. His discussion of realloc specifically calls for byte-wise copying of the preserved initial portion, with the intended consequence of preserving effective type.
The included appendix presents those edits as difference-marked pages. They are not contiguous pages of a complete replacement standard. That format matters when reading the proposal because a changed paragraph relies on surrounding definitions that the appendix may not reproduce. The submitted document's own scope remains clarification of the model.
The suggested terminology would let allocation, representation and lifetime sections refer to the same reserved region consistently. It would also leave object type and address as separately described properties. The value of the proposal depends on maintaining those distinctions throughout the wording, especially where one allocation contains several objects or an address is reused after an earlier lifetime ends.