Conversation

Is taking a pointer to the interior of a contiguously-laid-out array, then shortening the length of the array and dereferencing that now-dangling pointer, a spatial or temporal memory safety violation? Seems to me that the distinction gets very blurred in this case.

Replying to

I think it's a temporal error. If you shorten an array (assume correctly), then the array was re-allocated, similar to what realloc() does. So it's semantically a new array, and thus the old ptr becomes dangling and dereferencing it is a use-after-free.

Replying to

and

Depends on your definition of "shorten". Some definitions explicitly promise not to reallocate. C++ std::vector::resize() for example.

Replying to

and

Yeah I used "re-allocate" as a semantic concept, not how it's implemented. Like libc's realloc() may not really call free() and malloc() internally, but keep everything in place if space permits. However, semantically it can still be regarded as a reallocation.

Replying to

and

I don't think it works semantically either. All of the in-bounds references into the array remain valid after shortening. That would not be the case for a true reallocation.

Replying to

and

Growing and shrinking are semantically very similar operations. They're nearly the same thing for all commonly used sizes with modern allocators. They round to a size class and if the size class is smaller or larger than before it has to be moved to a new allocation elsewhere.

8:57 PM · Sep 9, 2022Twitter Web App

Replying to

Expecting shrinking not to reallocate is a misconception not aligned with how modern allocators work. For example after an initial 4 special cases for 16, 32, 48 and 64, jemalloc has 4 size classes per doubling of size. 897 byte alloc rounds to 1024. Shrink to 896 and it's moved.

Replying to

and

Again, depends on your definition of "shrink". Some array shrink operations (e.g. C++ std::vector::resize) are guaranteed not to involve the allocator.

Show replies