I'm not at all clear on how exactly that would work. The entire program would have to be rebuilt from scratch, would it not? Things like std::vector::operator[] are not runtime library calls, they are almost always inlined by the compiler. You could not simply take an existing program, replace its runtime library, and get bounds-checked vector accesses.
Of course, it is a compiler feature, you will have to recompile and manually (or automatically) apply all suggested changes to the source code.
If you just link against an hardened library, only the implementation of the (non inlined) library calls will be hardened, the user code itself won't see much benefits.
Of course these days we have binary level optimizers, so who knows what it is possible in principle?
Sorry, I used 'link' very liberally there, but you cleared it up. My point was that (from what I remember, it's been a few days) you'd mostly just need to recompile. As opposed to, you know, Rewrite It In Rust (TM).
Even if not inlined at -O0, when instantiated for a custom some_type, the standard library .so won't contain any code for it, everything will be in the application binary.
It’s difficult to imagine which applications would find the performance of an outline vector access acceptable. Generally vector::operator[] is represented in built programs by a single x86 mov. A call would wreck the performance. In languages with bounds-checked vectors, they don’t do it with library calls.
I have practically always used bounds checked vectors and strings.
In the old days, all C++ frameworks bundled with compilers tended to have bounds checking enabled by default (Turbo Vision, OWL, VCL, MFC, PowerPlant, CSet++, Qt,...).
Nowadays I always set _ITERATOR_DEBUG_LEVEL to 1 on VC++, unless I am not allowed to.
Mostly the performance problems that were dealt with, had to do with badly chosen algorithms and data structures.
