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. > 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? My vote here is therefore to stop getting deeper into this rabbit-hole. > The comment in lib/string.in.h is somewhat misleading: > > /* Declarations for ISO C N3322. */ > #if defined __GNUC__ && __GNUC__ >= 15 && !defined __clang__ > # ifndef memcpy > _GL_EXTERN_C void *memcpy (void *__dest, const void *__src, size_t __n) > # if __GLIBC__ + (__GLIBC_MINOR__ >= 2) > 2 > _GL_ATTRIBUTE_NOTHROW > # endif > _GL_ATTRIBUTE_NONNULL_IF_NONZERO (1, 3) > _GL_ATTRIBUTE_NONNULL_IF_NONZERO (2, 3); > > glibc's <string.h> has the nonnull attribute in memcpy. Adding the > above nonnull_if_nonzero declaration doesn't cancel the nonnull > attribute from glibc's header, so the above is effectively a no-op. I disagree. This piece of code adds nonnull_if_nonzero declarations, and with it it adds improved diagnostics (especially on non-glibc platforms). > However, in GCC >= 15 the builtin > memcpy already has these attributes, so for memcpy and other builtins > the above does nothing. Only non-builtins might benefit. I don't want to assume much about gcc's built-ins. Even if you are right, the built-ins can change in the future, and gcc-compatible compilers like clang possibly have different ones. Bruno
