Broadening compiler checks for buffer overflows in _FORTIFY_SOURCE (2021)

Ahh, I came across this article trying and failing to rebuild glibc in debug mode on Arch Linux, and it would always error out due to _FORTIFY_SOURCE (eeg. <a href="https:&#x2F;&#x2F;bbs.archlinux.org&#x2F;viewtopic.php?id=245755" rel="nofollow">https:&#x2F;&#x2F;bbs.archlinux.org&#x2F;viewtopic.php?id=245755</a>). IIRC I tried creating a chroot but ran into the same error (or couldn&#x27;t make the chroot work, forgot which). In the end I gave up rebuilding glibc in debug mode (since it would&#x27;ve slowed down <i>all</i> my programs). I still don&#x27;t know what I did wrong; maybe glibc is just incompatible with optimizations off.<p>Nowadays Arch uploads package symbols to debug packages and servers accessible by debuginfod (<a href="https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;title&#x2F;Debugging&#x2F;Getting_traces" rel="nofollow">https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;title&#x2F;Debugging&#x2F;Getting_traces</a>), but I&#x27;ve observed debuginfod <i>greatly</i> slows down gdb and valgrind and strace (so I don&#x27;t set the DEBUGINFOD_URLS environment variable by default, only when actually debugging).

So _FORTIFY_SOURCE adds checks to functions like memcpy(), but seems to do nothing to help custom code that uses for loops and array indexing.<p>I guess I&#x27;ll keep using -fsanitize=address (ASan) in my debug builds.

&gt; This promises to significantly widen fortification coverage to include cases where the compiler can see the non-constant expression for object size.<p>Any stats on the coverage increase?

I understand the need for constructions like this, and I understand the limitations you work with when dealing with older languages such as C or C++, but does anyone else think that this is just incredibly hacky?<p>I mean, this is the kind of stuff that needs to be taken care of at the language level. But I guess that&#x27;s impossible, so we have this instead. Still, progress! I guess.