On Fri, Dec 1, 2023 at 8:15 AM Bruno Haible <br...@clisp.org> wrote: > > [CCing bug-gnulib because obstack.c comes from gnulib.] > > Alexey Palienko <alexey.palie...@cma.se> 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
I think that's a valid finding. NULL is not a valid address. You can't add anything to it. Jeff