On Wed, 2020-06-24 at 16:16 +0200, Richard Biener wrote: > On Wed, Jun 24, 2020 at 4:14 PM Jonathan Wakely via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > On 24/06/20 12:31 +0200, Ilya Leoshkevich wrote: > > > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le- > > > redhat-linux > > > and s390x-redhat-linux. > > > > > > Ok for master? > > > > > > --- > > > > > > Bootstrap with musl libc fails with numerous "missing sentinel in > > > function call" errors. This is because musl defines NULL as 0L > > > for C++, > > > but gcc requires sentinel value to be a pointer or __null. > > > > > > Jonathan Wakely says: > > > > > > To be really safe during stage 1, GCC should not use NULL as a > > > pointer sentinel in C++ code anyway. > > > > > > The bootstrap compiler could define it to 0 or 0u, neither of > > > which > > > is guaranteed to be OK to pass as a varargs sentinel where a > > > null > > > pointer is expected. Any of (void*)0 or (void*)NULL or > > > nullptr > > > would be safe. > > > > > > Therefore, fix by replacing NULL sentinels with nullptr. > > > > For some additional context, the C++ standard guarantees that > > passing > > nullptr to a varargs function will convert to (void*)0. That has > > been > > true since nullptr was added in C++11. > > Is there a diagnostic option that we can turn on so no NULLs will > creep > in in such position? Without that we'll bitrot quickly?
I couldn't find a useful existing warning for this. The main difficulty in implementing it, as far as I can see, is that we need to check preprocessor tokens that were used to generate a function argument. Can we somehow compare the source code of a function argument with "NULL"? At least diagnostic code should already able to access the original (non-preprocessed) source code, can the warning code do this as well? > > Richard.
