Thanks for doing the research. > Date: Sun, 8 Mar 2020 15:30:02 +0100 > From: Kamil Rytarowski <n...@gmx.com> > > 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.