Re: NULL pointer arithmetic issues

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

Thanks for doing the research.

> Date: Sun, 8 Mar 2020 15:30:02 +0100
> From: Kamil Rytarowski <n54%gmx.com@localhost>
> 
> NULL+0 was added to UBSan proactively as it is as of today not
> miscompiled, but it is planned to so in not so distant time. It is a
> chicken-egg problem.

If you say it is planned, can you please cite the plan?

In C++, adding zero to a null pointer is explicitly allowed and
guaranteed to return a null pointer.  See, for example, C++11 5.7
`Additive operators', clause 7, p. 117: `If the value 0 is added to or
subtracted from a pointer value, the result compares equal to the
original pointer value.'  C++17 clarifies in 8.7 `Additive operators',
clause 7, p. 132: `If the value 0 is added to or subtracted from a
null pointer value, the result is a null pointer.'

So it would be a little surprising to me if compilers -- which tend to
focus their efforts on C++ more than C these days -- went out of their
way to act on the inference that evaluating p + 0 implies p is nonnull
in C.

> There is however a fallback. If we want to use NULL+0, we must use
> -fno-delete-null-pointer-checks that avoids miscompilation and raising
> UBSan reports. If we want to allow NULL+x we must enable -fwrapv.

Adding -fno-delete-null-pointer-checks for clang too sounds sensible
to me in general, but please check with joerg first.  It remains
unclear to me that it's necessary here.