the object has exactly two states:
u (unprepared)p (prepared)no other state is semantically relevant.
semantic state is defined only by successful transitions and external resource ownership.
representation state is the concrete byte contents of the object.
the automaton constrains semantic state only.
state is determined by successful transitions:
init -> uinit and before uninit -> puninit -> ufailed init attempts are not transitions.
u -> p
obligations:
obligations on failure:
init call on the same object is validinit is total on u.
p -> u
obligations:
non-obligations:
uninit is total on p.
p -> p via initu -> u via uninituninit before a successful initup implies all runtime invariants holdu implies no external resources are owneduu is unconstrained except that init is permittedinit is atomic with respect to semantic state at function return:
u or pbecause:
init is total on uuninit returns p -> uinit leaves the object in uthe sequence:
`u` -> init -> `p` -> uninit -> `u` -> init -> ...
is always valid.
the automaton is correct if and only if:
pinit leaves the object in u and permits another initinit and uninit are mutual inverses on semantic stateAny external resource whose ownership would characterize the p state (being a property of it) should, from the moment of acquisition, be represented in the object. No such direct ownership may be staged or duplicated in locals for later publication.
On failure return from init, the implementation performs only the releases necessary to ensure that the object owns no external resources. It performs no additional representation writes for restoration, normalization, or repair.
init is defined to operate correctly on any representation satisfying the u invariant, independent of its byte contents. The sole semantic requirement on failure is therefore: no external resources remain owned.