> 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.
> 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,
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:
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.
[1]: https://news.ycombinator.com/item?id=40361096
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.
That at least has been covered almost since C++ exists.
First in compiler vendors frameworks, pre C++98, afterwards with build settings.
It is quite telling from existing community culture, that some folks only read their compiler manuals when government knocks on the door.
>It is quite telling from existing community culture, that some folks only read their compiler manuals when government knocks on the door.
What do you want to say?
Is this bad? I think this is desired. Only in c or c++ world people act like understanding how compiler internals work (often poorly) is desired
Where in the world reading a compiler manual means understanding compiler internals?!?
One does not need to understand compiler internals to be aware what build flags are used to turn bounds checking on the standard library.
> 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.
1 reply →
I have never known a situation where LESS knowledge about the compiler (flags, options, hell even internal workings) have been better - on the contrary.
This is why you should have an option (enabled routinely in your CI) to run your tests under valgrind.
I do this too, but valgrind is slow! In my experience, the runtime increases a factor of 10/20/30x ..
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.
1 reply →