Re: undefined-behavior obstack.c:139

[CCing bug-gnulib because obstack.c comes from gnulib.]

Alexey Palienko <[email protected]> wrote in
<https://lists.gnu.org/archive/html/bug-m4/2023-02/msg00000.html>:

> It has been built by clang 13 with "-g -fsanitize=address,undefined -fno-omit-frame-pointer -fsanitize-address-use-after-scope -fno-sanitize-recover=all"
> And we have an error:
>
> # /home/docker/.conan/data/m4/latest/_/_/package/3421fde5744f1eadef515027cbcbb9a8fbcd667c/bin/m4
> obstack.c:139:35: runtime error: applying non-zero offset 107820858999056 to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior obstack.c:139:35 in

I reproduce the issue with the newest m4 snapshot and with clang 17.

However, it's not a bug in m4, but rather a false alarm from clang's
UndefinedBehaviorSanitizer.

Namely, when I use the modified CC value
  CC="clang -fsanitize=address,undefined,signed-integer-overflow,shift,integer-divide-by-zero -fno-sanitize=pointer-overflow -fsanitize-address-use-after-scope -fno-sanitize-recover=all"
there are no issues.

The 'pointer-overflow' sanitizer considers adding NULL + 0 as undefined:
========================
#include <stdlib.h>
int main ()
{
  char *p = NULL;
  char *q = p + 0;
  return 0;
}
========================

I don't see wording to this effect in ISO C 23 § 6.5.6.(9).
Many programs use NULL + 0 in some cases, because it avoids a gratuitous
test against NULL.

So, I recommend turning off the 'pointer-overflow' sanitizer.

Bruno

[1] https://gitlab.com/gnu-m4/ci-distcheck