A really good accompaniment to this is Carruth's "C++, bounds checking, performance, and compilers" [1]:
> ... strong belief that bounds checks couldn’t realistically be made cheap enough to enable by default. However, so far they are looking very affordable. From the above post, 0.3% for bounds checks in all the standard library types!
There's more to the hardening story than just bounds checks. But it's a big part IMO.
> Even if bounds checks were only active in debug builds
In MSVC or Clang, when compiled against the Microsoft C++ STL, they already are. So,
auto x = std::vector{1, 2, 3, 4, 5};
std::println("{}", x[5]);
throws a very specific exception at runtime under debug mode.
In fact on Windows, even the C runtime has debug checks. That's why there are four options to choose from when linking against the modern UCRT:
/MT (static linking, no debug)
/MTd (static linking, with debug)
/MD (dynamic linking, no debug)
/MDd (dynamic linking, with debug)
For what 'debug in the C runtime' entails, see this comment I made a while ago[1]. As I mentioned, Unix-likes have no equivalent; you get one libc, and if you want to statically link against it, you have to release your own source code because it's GPL. Not sure why people put up with it.
Not sure what you mean by "Not sure why people put up with it". Glibc is licensed under LGPL, so you can distribute it proprietary software even with static linking under some conditions. And there also other alternatives.
It mostly impacts templated code, so it's a compiler flag, not a linker flag. Many distributions have been using this flag to build C++ code for quite some time.
(And this concerns GNU libstdc++, not glibc, so different licensing rules apply.)
A considerable number of C++ libraries are header-only, so having this macro defined is the onus of the libraries' consumers, rather than just the package managers'.
Also, I mentioned no libc equivalent, and that remains true. Regardless of the libc distribution (glibc, musl, BSD, macOS libSystem), none of them have a debug mode in the vein that Windows UCRT does.
glibc has -D_FORTIFY_SOURCE, which uses several GCC and clang builtins and features along with hardened alternative function implementations to enable additional compile-time and runtime checks.
> Only in c or c++ world people act like understanding how compiler internals work (often poorly) is desired
I think this says more about other parts of the developer ecosystem than about C and C++. Understanding how the compilers work (and how CPUs work) is fundamental to software development.
I have never known a situation where LESS knowledge about the compiler (flags, options, hell even internal workings) have been better - on the contrary.
Yes, it's definitely slow. That's why we have an option to run the same tests normally or with valgrind, and mainly use valgrind runs in our CI system after changes have been committed.
> ... strong belief that bounds checks couldn’t realistically be made cheap enough to enable by default. However, so far they are looking very affordable. From the above post, 0.3% for bounds checks in all the standard library types!
There's more to the hardening story than just bounds checks. But it's a big part IMO.
[1] https://chandlerc.blog/posts/2024/11/story-time-bounds-check...