Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
Joerg Sonnenberger wrote: > On Thu, Nov 04, 2021 at 06:30:29PM -0600, Theo de Raadt wrote: > > Joerg Sonnenberger 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 I call bullshit. I've watched you for years. You talk a lot and fix very little source code. And quite often, it feels like you advocate against things which help. There's a well-known phrase Why not both? Compile time errors *already exist*. For you to come here to our lists and advocate against a mechanism we have found incredibly effective, is a bullshit against-improvement process. Please stop your shit.
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Thu, Nov 04, 2021 at 06:30:29PM -0600, Theo de Raadt wrote: > Joerg Sonnenberger 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
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
Joerg Sonnenberger 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.
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
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. Joerg
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Mon, Oct 25, 2021 at 07:41:51AM -0600, Todd C. Miller wrote: > On Mon, 25 Oct 2021 12:48:01 +1100, Jonathan Gray wrote: > > > Shouldn't lld instead be changed to show warnings? > > That was my thinking as well. After discussing the matter with other developers during h2k21, this is indeed the consensus. 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. There is an issue [2] in the LLVM bugtracker about adding support in LLD to generate linker warnings when encountering these sections, I will see what can be done on that topic. [1] https://github.com/fcambus/gwcheck [2] https://bugs.llvm.org/show_bug.cgi?id=42008
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Mon, 25 Oct 2021 12:48:01 +1100, Jonathan Gray wrote: > Shouldn't lld instead be changed to show warnings? That was my thinking as well. - todd
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Sun, Oct 24, 2021 at 02:27:55PM +0200, Frederic Cambus wrote: > Hi tech@, > > This diff removes mentions of ld warning messages for mktemp(3), > tmpnam(3), and tempnam(3). > > LLD doesn't emit warnings when encountering .gnu.warning.* sections, so > those warnings are not emitted anymore for a majority of users since we > switched to LLD as the default linker on most architectures. > > Manual pages for other libc functions for which we have .gnu.warning.* > sections did not mention ld warnings. For the record, those functions > are: getwd(3), rand(3), rand_r(3), random(3), sprintf(3), stpcpy(3), > strcat(3), strcpy(3), vsprintf(3), wcscat(3), and wcscpy(3). > > Comments? OK? Shouldn't lld instead be changed to show warnings? > > Index: lib/libc/stdio/mktemp.3 > === > RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v > retrieving revision 1.54 > diff -u -p -r1.54 mktemp.3 > --- lib/libc/stdio/mktemp.3 26 Oct 2014 12:54:18 - 1.54 > +++ lib/libc/stdio/mktemp.3 24 Oct 2021 10:38:29 - > @@ -408,8 +408,3 @@ Whenever it is possible, > or > .Fn mkdtemp > should be used instead. > -.Pp > -For this reason, > -.Xr ld 1 > -will output a warning message whenever it links code that uses > -.Fn mktemp . > Index: lib/libc/stdio/tmpnam.3 > === > RCS file: /cvs/src/lib/libc/stdio/tmpnam.3,v > retrieving revision 1.23 > diff -u -p -r1.23 tmpnam.3 > --- lib/libc/stdio/tmpnam.3 30 Aug 2019 23:33:45 - 1.23 > +++ lib/libc/stdio/tmpnam.3 24 Oct 2021 10:38:29 - > @@ -219,10 +219,3 @@ temporary files are created. > .Pp > This implementation does not have these flaws, but portable software > cannot depend on that. > -.Pp > -For these reasons, > -.Xr ld 1 > -will output a warning message whenever it links code that uses the functions > -.Fn tmpnam > -or > -.Fn tempnam . > >
Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
Hi tech@, This diff removes mentions of ld warning messages for mktemp(3), tmpnam(3), and tempnam(3). LLD doesn't emit warnings when encountering .gnu.warning.* sections, so those warnings are not emitted anymore for a majority of users since we switched to LLD as the default linker on most architectures. Manual pages for other libc functions for which we have .gnu.warning.* sections did not mention ld warnings. For the record, those functions are: getwd(3), rand(3), rand_r(3), random(3), sprintf(3), stpcpy(3), strcat(3), strcpy(3), vsprintf(3), wcscat(3), and wcscpy(3). Comments? OK? Index: lib/libc/stdio/mktemp.3 === RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v retrieving revision 1.54 diff -u -p -r1.54 mktemp.3 --- lib/libc/stdio/mktemp.3 26 Oct 2014 12:54:18 - 1.54 +++ lib/libc/stdio/mktemp.3 24 Oct 2021 10:38:29 - @@ -408,8 +408,3 @@ Whenever it is possible, or .Fn mkdtemp should be used instead. -.Pp -For this reason, -.Xr ld 1 -will output a warning message whenever it links code that uses -.Fn mktemp . Index: lib/libc/stdio/tmpnam.3 === RCS file: /cvs/src/lib/libc/stdio/tmpnam.3,v retrieving revision 1.23 diff -u -p -r1.23 tmpnam.3 --- lib/libc/stdio/tmpnam.3 30 Aug 2019 23:33:45 - 1.23 +++ lib/libc/stdio/tmpnam.3 24 Oct 2021 10:38:29 - @@ -219,10 +219,3 @@ temporary files are created. .Pp This implementation does not have these flaws, but portable software cannot depend on that. -.Pp -For these reasons, -.Xr ld 1 -will output a warning message whenever it links code that uses the functions -.Fn tmpnam -or -.Fn tempnam .
