In my experience, the assertions enabled by _GLIBCXX_ASSERTIONS are incredidbly important and effective, but sadly nowhere near as well known or widely used as they deserve to be. Lately, C++ has been attracting negative attention for security, and using _GLIBCXX_ASSERTIONS is probably one of the most efficient and easy ways to improve things in the short term. Should the checks enabled by _GLIBCXX_ASSERTIONS enabled by default in debug builds (somewhat like with NDEBUG and the assert macro), effectlively making them "opt-out" instead of "opt-in"? This will allow a lot of latent security bugs to be detected before software is put into production. This will have a performance hit on unoptimized builds, but my experience so far is that the performance hit on optimized builds is small because the optimizer is very often able to figure out that the checks are redundant, and will remove them. I think making these checks enabled by default in debug builds will have huge positive impact on the security of C++ code bases, at an acceptable cost. It also sends a message that the language add tools is evolving in a more secure direction.
Yes I've been considering making them opt out for a while (maybe even in optimized builds). The libstdc++ config can use #ifndef __OPTIMIZE__ to detect when building without optimization.
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664289.html
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>: https://gcc.gnu.org/g:361d230fd7800a7e749aba8ed020f54f5c26d504 commit r15-4208-g361d230fd7800a7e749aba8ed020f54f5c26d504 Author: Jonathan Wakely <jwakely@redhat.com> Date: Thu Sep 26 16:55:07 2024 +0100 libstdc++: Enable _GLIBCXX_ASSERTIONS by default for -O0 [PR112808] Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing valuable checks for C++ standard library preconditions. This change enables libstdc++ assertions by default when compiling with -O0 so that we diagnose more bugs by default. When users enable optimization we don't add the assertions by default (because they have non-zero overhead) so they still need to enable them manually. For users who really don't want the assertions even in unoptimized builds, defining _GLIBCXX_NO_ASSERTIONS will prevent them from being enabled automatically. libstdc++-v3/ChangeLog: PR libstdc++/112808 * doc/xml/manual/using.xml (_GLIBCXX_ASSERTIONS): Document implicit definition for -O0 compilation. (_GLIBCXX_NO_ASSERTIONS): Document. * doc/html/manual/using_macros.html: Regenerate. * include/bits/c++config [!__OPTIMIZE__] (_GLIBCXX_ASSERTIONS): Define for unoptimized builds.
Done for GCC 15.
Thank you for doing this. I think this will have a big impact. I do hope that when this has been in use for a while and users have fixed most of the bugs that it will reveal, then perhaps you can enable it for release/optimised builds as well (perhaps even in gcc 16?). I think that have a huge impact on security, and it may not affect performance nearly as much as many think: https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/
My plan was/is to wait for the 15 cycle to be done, see if any reports come in, and go from there and ask Jonathan what he thinks. I have been filing some missed-optimisation bugs when _GLIBCXX_ASSERTIONS is enabled but so far they're not bad.
By the way, Helge, I also got Meson defaulting to this whenever NDEBUG isn't enabled last year and we had very few complaints.