Object lifetimes: when an address stops being a resource

For this lesson, a buffer is allocated at time a, initialized before its first read, and released at time d. An ordinary access to its bytes must occur while the allocation remains live. A local variable containing an address may remain in scope after d, but its continued existence does not extend the buffer's lifetime. Stack storage can become invalid when a function returns; heap storage can become invalid when an owner releases it. Neither storage category permits arbitrary late access. Language rules can distinguish storage duration from the lifetime of a particular object placed there.

The interval test is deliberately incomplete. A pointer into a live allocation can still have the wrong alignment, insufficient accessible length, invalid provenance, an uninitialized value, or conflicting access permissions. A memory-mapped device may require additional rules. Treat lifetime as one required condition rather than a complete safety certificate. In a review, first identify the allocation's owner and release event, then check the access-specific obligations. This method exposes a missing lifetime argument without pretending to replace the target language's formal memory model.

Imagine a decoder releasing a buffer and an allocator subsequently placing a different request's data at the same numerical address. A stale pointer can now appear to read reasonable bytes, creating a more confusing failure than an immediate crash. The new allocation has a different history and ownership contract. Reasoning solely from equal addresses misses that distinction. Safe interfaces therefore preserve an owning handle, borrow, or validated object identity rather than asking whether an old pointer still seems to work during a convenient test execution.

Invalidation can also occur during growth. A resizable container may obtain a new backing allocation and release the old one; a reference to an earlier element must not survive an operation that invalidates it. Whether a particular operation reallocates is an API question, and avoiding reallocation in one run is weaker than proving that the operation preserves references. Record the documented invalidation rules. When an asynchronous consumer retains a buffer, completion must include the consumer's final possible read, including cancellation and error paths, before reuse becomes justified.

Keeping a buffer alive indefinitely can avoid one premature-release error while exhausting memory. Conversely, aggressively reusing buffers can reduce memory and introduce use-after-release. Establish an explicit lifecycle: acquisition, exclusive initialization, publication to readers, confirmation that readers have finished, and reclamation. For each transition, name the responsible component and the evidence it observes. A timeout often ends the caller's willingness to wait; it does not automatically prove a native worker or remote device has stopped accessing shared memory.

The queue lab illustrates retention pressure, not pointers. Interpret each waiting job as owning one equal-sized buffer. Press Reset, set arrival rate to four and service rate to two, then Play or Step; the fluid backlog begins at four and grows by two jobs per second. For a separate run, press Reset before setting arrival rate to two and service rate to four. Predict that the restored four-job backlog drains in two seconds, then Play or Step. Multiply the readout by an assumed buffer size to estimate waiting payload. The model omits executing jobs, allocator behavior, and all lifetime checks. Use that limitation to explain why a stable queue can still contain a dangling pointer, while a perfectly safe queue can still retain too much memory.