C++26: Standard library hardening
7 points by raymii
7 points by raymii
It’s interesting how negligible the performance is, per Google's analysis. I remember the hand-wringing back in the 90s about the cost of array bounds checks and null-pointer checks in Java. I assume it’s a combination of better compiler optimizations and better CPU instruction scheduling.
It still happens to this day. C++ developers saying "performance at all costs" with things like "just use Vec<>.at() if you want bounds checking".
Yup: it turns out that because no one was doing bounds checking none of the c/c++ compilers were really optimizing them at all. The obvious result "don't do bounds checking, it's really expensive" -> no one bounds checks -> no reason to optimize bounds checking -> ....
The -fbounds-safety work is what drove a lot of the clang bounds checking optimizations, I don't know the story in gcc-land.
Its fun how Google gets cited when their numbers support what the C++ community wants to do, while the entire company is supposedly a clownshow that can not write decent C++ code in all other cases.
Also funny: They standardized a feature that was in all compilers but left out the one thing they all did differently: How to activate the entire thing.
You mean their C++ like blink, or something else?
Also funny: They standardized a feature that was in all compilers but left out the one thing they all did differently: How to activate the entire thing.
So very dumb, but on the other hand the point of standardizing was so that if you do enable it you are getting the same guarantees regardless of compiler/stdlib implementation rather than some ad hoc set.
0.3% performance overhead
What is the size overhead? And what is the perfomance overhead on an in-order core? Without branch prediction? Remember all the embedded devices this is going to run on.
Size impact is negligible as well. If you're concerned about performance you wouldn't be using an in order core, and of course the myriad mitigations needed to compensate for unsafe C and C++ is much more expensive than 0.3%.
Of course, no one is forcing you to enable this, you can choose to skip the single command line flag to enable the protection if you want, but if it turns out that command line flag would have prevented an exploitable bug that might not be the best look from a marketing point of view.