https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409
--- Comment #8 from Yaakov Selkowitz <yselkowi at redhat dot com> --- (In reply to Andrew Pinski from comment #3) > In fact this is by design. NetBSD for an example has ssp/stdio.h where you > use that to get the fority. This does not apply where the libc provides its own SSP functionality. In fact, part of the fix for this will be noconfigdirs+=target-libssp on such targets, as the libssp implementation conflicts. (In reply to Andrew Pinski from comment #4) > What I am trying to say is there is no security hole that this can cause, > only the badly written applications where the security holes are located. This was judged CVE worthy because a security barrier did not function as expected. > Also this looks like it was by design. Then the design is poor, as it does not work. (In reply to Andrew Pinski from comment #6) > And really not true even for the current version of netbsd but they do: > 1.70 kristerw 596: #if _FORTIFY_SOURCE > 0 > 1.69 tls 597: #include <ssp/stdio.h> > 1.70 kristerw 598: #endif > > http://cvsweb.netbsd.org/bsdweb.cgi/src/include/stdio.h#rev1.69 > > So again I don't see this as a bug but rather the person thinking > -D_FORTIFY_SOURCE works without including ssp/*.h on some targets. No, as documented, the only necessary intervention is to define _FORTIFY_SOURCE; the location of the headers is implementation specific.