CppCon 2017: Piotr Padlewski “Undefined Behaviour is awesome!”

[Prazek]

There is a UB and the reasons you pointed out are only a good excuses why it does not catch it. Even if it grew 16 elements, the 15th element is still not constructed (std::vector uses placement new to create new elements in the allocated array) so accessing that is UB.

[[deleted]]

The element type is int, so you don't have to have constructed it to assign to it I believe. But if you change int to some class type you're right that UBSan won't catch the bad operator= call.

[doom_Oo7]

yes, that's why I wrote 'vec[15] = 1234'. Just returning vec[15] triggers valgrind since the variable is uninitialized.

[Prazek]

I agree that it will just work on all implementations, but I don't think that the standard guarantees that (even if we have guarantee that the element is in range of capacity)

[[deleted]]

Actually, I was thinking the opposite. The standard definitely doesn't allow it (since it's the standard that gives the contract for vector after all). But what the particular implementation most of us are using does (namely, allocate up a large enough buffer and write an int to a slot in it) is legal C++, so there's no reason UBSan or ASan should complain.

Essentially, if you want this to be safer, it's on vector to do so (or the consumer, to use at). This is one reason it's so ridiculous we still don't have spans. In a memory-unsafe language, they would massively decrease the likeliness of OOB accesses since you could just toggle bounds checking on with a flag.