Comment by delta_p_delta_x
4 days ago
> 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.
The GNU equivalent is -D_GLIBCXX_ASSERTIONS: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...
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.