Paul Eggert wrote: > > Indeed, this sentence appears to forbid ((char *) NULL) + something. > > Yes. However, Gnulib code can still use ((char *) NULL) + something) > because the Gnulib portability guidelines allow it. > > The issue with clang false positives is covered here: > > https://www.gnu.org/software/gnulib/manual/html_node/Unsupported-Platforms.html > > which lists "clang -fsanitize=undefined" as an unsupported platform > unless you also specify "-fno-sanitize=pointer-overflow".
But, as the Gnulib documentation says, "this may also disable some unrelated and useful pointer checks". And indeed, the runtime error from the obstack module was hiding two other runtime errors (undefined behaviour) in GNU m4: <https://lists.gnu.org/archive/html/bug-m4/2023-12/msg00011.html>. These two other cases became visible only after the 'obstack' one was eliminated (due to the option '-fno-sanitize-recover=all', which is generally reasonable to use). So, while we are unhappy about changing our code, it allows more people to make good use of clang's UB sanitizer. Much like the problem we had with memset (NULL, c, 0); or memcpy (dest, NULL, 0); There also I hated to change source code, to accommodate a picky sanitizer. But the benefit is that the sanitizer can be applied during development and won't give a false alarm. > However, we needn't go through Gnulib and change > other code merely because it runs afoul of this false alarm from clang. On the contrary, I will try to find and eliminate such alarms. Bruno