I’m afraid this might be too little, too late. But regardless whether I’m right or wrong, we all should welcome a widely used language trying to become a little more safe.
If I'm reading this correctly, this has two components:

- a bound checked libc++, which is not particularly exciting, libstdc++ has had _GLIBCXX_ASSERTIONS for a while for example. In fact it seems that libc++ has had it as well.

- clang warnings to flag potentially unsafe code plus fix-it suggestions to convert it to safer code using the bound checked libc++.

The later is quite interesting, especially the fix-it might make it easier to incrementally "harden" a large c++ code base.

This is unfortunately ABI-altering, therefore it won’t be possible to selectively enable for projects that want it. It’s a distribution that has either to bite the bullet and say “we are going to pessimize all C++ software”, or err on the safe side and leave it disabled.

The warning about pointer arithmetic is most likely suppressable per compilation unit (for things like tagged pointers).

I'm curious if this will get done and adopted. This is where "Modern C++ is a safe language" needs to walk the walk.
> For example, accessing a std::span or a std::vector outside of its bounds would abort the program, and so would accessing an empty std::optional. This can be done while staying Standards-conforming because undefined behavior implies that the library can do whatever it wants, which includes aborting.


Getting bad operations to abort execution (e.g. by throwing an exception) seems impossible to ship, not in the least due to certain, uh, entities really being against it. But abusing UB to allow people to turn on checks is excellent. This is why we should be very careful about what we choose to standardize-a common request is making signed overflow wrap instead of being UB, which prevents its diagnosis in this way.

This is great news. Such hardening can already be compiled in C code, and is even shipping in some projects, e.g. the Linux kernel has a CONFIG_UBSAN option which activates compiler sanitizers for things like array bounds checks that will panic on failure. Makes sense to extend similar behaviour to projects based on C++ codebases.
Could it detect the use of an iterator after a vector<> push_back()