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.
7
16
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.
1
2
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.
1
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.
1
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.
1
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.
2
Patrick's initial problem description seems to fit the length-not-capacity case equally well. He's not using technically precise language. Seems fine to map "shorten" == std::vector:resize and "dangling pointer" == invalidated iterator.
1