Description
Location
https://doc.rust-lang.org/nightly/std/alloc/trait.Allocator.html
Summary
The documentation for the grow()
, grow_zeroed()
, and shrink()
methods contains an implication that it is not unsound (though also not recommended) for these methods to panic.
Clients wishing to abort computation in response to an allocation error are encouraged to call the
handle_alloc_error
function, rather than directly invokingpanic!
or similar.
But, it is important for the caller to handle outcomes correctly to avoid either leaking or accessing freed memory:
If this returns
Ok
, then ownership of the memory block referenced byptr
has been transferred to this allocator. The memory may or may not have been freed, and should be considered unusable.If this method returns
Err
, then ownership of the memory block has not been transferred to this allocator, and the contents of the memory block are unaltered.
Thus, I think that the documentation should also mention the caller's responsibility in case of unwind, i.e. if the call panics. I see two coherent possibilities:
- A panic is a bug in the allocator; the caller must make no assumptions, and thus must not touch
ptr
further (potentially leaking an allocation). - A panic is a way of signaling allocation failure; it should be treated similarly to
Err
, andptr
is still valid. Therefore, unwinding should leave the owner ofptr
in a valid state, and deallocateptr
on drop.
In either case, I think the documentation should explicitly describe unwind considerations.