On Thu, Nov 04, 2021 at 06:30:29PM -0600, Theo de Raadt wrote: > Joerg Sonnenberger <jo...@bec.de> wrote: > > > On Thu, Nov 04, 2021 at 10:12:32PM +0100, Frederic Cambus wrote: > > > I'm building myself a small tool [1] to display .gnu.warning.* sections > > > names in ELF objects along with their content, and will check which > > > other projects use those sections. So far, aside from us, FreeBSD, > > > NetBSD, and DragonFly all use these sections in their libc, and glibc > > > does as well. > > > > In the past, the linker section was the only option to get usage > > warnings. It has the major downside that the implementation is somewhat > > buggy as GNU ld triggers the warning in a number of cases that do not > > include usage and there is no way to flag individual uses as safe. > > This disadvantage doesn't exist with the warning attribute. The downside > > of the attribute is that it requires very recent clang or modernish GCC > > to be supported. If it is supported, it provides a significant better > > user experience. > > And I believe that is false. > > Compile-time warnings scroll off the screen, and result in noone giving a > damn. > > When the warnings are at the very end, as they are with ld, at least > some people pay attention. > > I've been watching this for decades, and I can say with confidence that > everyone has learned to tune-out compile time warnings to a very high > degree.
I don't completely disagree about the compiler warnings, but they at least tell you where the problem is in a reasonable precise manner. We also now have reasonable good ways to selectively turn them into compiler errors. The ld warnings are worse in pretty much every way: - they are non-fatal by default as well - they are all or nothing - you can't whitelist individual warnings - they give very poor diagnostics for finding where the problem is - they have known false positives e.g. when using shared linking Joerg
