Skip to main content

Ownership and growth prediction practice

Predict before executing:

  1. Length and capacity are 4; allocation request for the fifth push fails. Which fields and values may change?
  2. The retry succeeds. May a saved pointer into the old storage be inspected to compare addresses?
  3. A failed allocation is counted as a request. Does it create a resource to free?
  4. The planner has current 8, needed 9, limit 9. What is valid? What if needed becomes 10?
  5. Why can a copied buffer struct cause a double release?
  6. What extra state would a buffer of objects with fallible copy callbacks require?

Calibration​

  1. None of the owner’s data, length or capacity changes; the allocator’s request counter can change.
  2. Do not evaluate expired pointers. Keep an index and use the new owner instead.
  3. No. Count successful live allocations separately from attempts.
  4. Capacity 9 is valid; needed 10 is rejected without changing the output argument.
  5. Both structs appear to own the same allocation; ownership was not transferred or duplicated safely.
  6. Track which new elements were constructed and how to roll them back before publication. The int-only lab deliberately avoids that additional failure model.

Repeat with a new capacity and failure point after a delay. Explain the state before using the reference implementation.