bemanproject / big_int / 32397899474

92%

Build Type

push

github

Committed by web-flow

Commit Message

Make assignment strong against a throwing allocation (#338)

* Make assignment strong against a throwing allocation

assign_value's slow path released the destination's buffer and published the
source's limb count before allocating, so a throw from alloc_limbs left the
control words describing freed storage. Reading it was a heap-buffer-overflow in
width_mag, destroying it was a double free, and on an inline destination the
value silently read as 0 and the next assignment overflowed the inline array.

The two branches that adopt existing storage now publish their control words
after that storage is in place. The fresh-allocation branch secures the new block
first, which leaves the destination unchanged on a throw rather than merely
valid.

Allocating first needs care when the allocator propagates, because the new block
has to come from the source's allocator while the old one still has to be
released with ours. Allocating through a copy of the source's allocator handles
that: [allocator.requirements.general] requires allocator copy construction not
to exit via an exception and gives a1 == a, and storage from equal allocators is
mutually deallocatable, so the block is releasable through m_alloc afterwards.
alloc_limbs is split into a static alloc_limbs_from taking the allocator
explicitly, with alloc_limbs forwarding to it.

Nothing between the allocation and the publication can throw: copy_n_to_allocation
is nothrow because the limb type is pinned to a builtin unsigned integer,
deallocate is required not to throw, and the propagating allocator assignment is
required not to throw when the trait is true.

The propagating path had no coverage at all, since no allocator in the suite set
propagate_on_container_copy_assignment. Three tests in allocation.test.cpp add a
stateful propagating allocator: one covers the fresh-allocation path, one the
move-assignment steal, and one arms a throw to check the destination keeps both
its value and its allocator.

* Dr... (continued)

Coverage Stats

13 of 15 new or added lines in 1 file covered. (86.67%)

1 existing line in 1 file now uncovered.

6044 of 6262 relevant lines covered (96.52%)

3137651.32 hits per line