On 2026-08-15 Bruno Haible wrote: > Lasse Collin wrote on 2026-08-03: > > I don't believe that the added UB from nonnull provides significant > > optimization benefits with many functions. A call with NULL might > > happen due a bug, and the extra UB from nonnull might make the bug > > more severe. The diagnostics part of nonnull (-Wnonnull and > > sanitizer) is great, but that should be achieved without creating > > more possibilities for UB. > > Well, compiler people disagree. They want to squeeze out every little > bit of speed. And NULL tests being conditional jumps, which can take > 20 cycles if branch prediction does not work well, are a worthy > target.
Those are valuable optimizations in general, I just think some cases go a bit far even if the standards allow it (like the examples in my earlier email). It's just an opinion of one person. Compilers could also have removed null pointer checks based on NULL + 0 being undefined, but luckily no compiler actually did that. As mentioned earlier, Clang doesn't optimize if it sees the nonnull attribute only in a function declaration. A discussion from 2017[1] gives an impression that glibc's headers might have been a reason for this. [1] https://discourse.llvm.org/t/rfc-do-not-optimize-on-basis-of-attribute-nonnull-in-glibc-headers/43547 > > N3322 function arguments won't assumed for now, but three commits > > already added Autoconf checks: > > > > e3915945e6dc memset_explicit: Guarantee N3322 functionality. > > 101b9d7f82f7 wcsncat: Guarantee N3322 functionality. > > bf799ba1fb48 strndup: Guarantee N3322 functionality. > > > > Should these Autoconf checks be disabled for now? These checks > > aren't complete, because they don't detect that the nonnull > > attribute in glibc's headers makes calls with NULL arguments > > undefined behavior. > > Your new unit tests show that programmers cannot rely on the absence > of nonnull declarations (at least for gcc). Therefore I think it does > not matter much whether the Autoconf tests catch this or not. > > And, practically speaking, how would you write an autoconf test that > _proves_ that the compiler is not seeing or assuming a nonnull > declaration? I don't think it's practical, which kind of was my point. Since applications using Gnulib cannot assume N3322 from those functions, replacing them if a N3322 check fails has limited value *now*, but maybe it's good to keep them enabled so they are ready for the future. By the way, it seems the check in m4/wcsncat.m4 fails on multiple platforms due to the same issue that is described in m4/strncat.m4 on Solaris where strncat can dereference n+1 bytes. See the second while-loop condition in OpenBSD's wcsncat[2]. The same issue is in NetBSD, but there is also a _DIAGASSERT that doesn't conform to N3322.[3] In FreeBSD it was fixed in 2016.[4] So even if one didn't care about the N3322 behavior at all, the N3322 check in m4/wcsncat.m4 is still useful. [2] https://cvsweb.openbsd.org/checkout/src/lib/libc/string/wcsncat.c,v?rev=1.4 [3] https://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/string/wcsncat.c?rev=1.3 [4] https://github.com/freebsd/freebsd-src/commit/cd3dbc2573cd943a968260679a48ffca39080ceb > My vote here is therefore to stop getting deeper into this > rabbit-hole. I agree. I'm very happy about the doc/gnulib-readme.texi update by Paul. Gnulib's docs have been valuable to me when I have needed information about portability issues. :-) Thanks for merging the other patches with your fixups, fixing memmove.c, etc. I didn't reply to those separately since I had nothing else to say there. -- Lasse Collin
