Re: undefined-behavior obstack.c:139

[Bruno Haible]

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