On 25/06/20 13:29 +0200, Ilya Leoshkevich wrote:
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
Doesn't -Wstrict-null-sentinel do it?
Warn about the use of an uncasted "NULL" as sentinel. When
compiling only with GCC this is a valid sentinel, as "NULL" is
defined to "__null". Although it is a null pointer constant
rather than a null pointer, it is guaranteed to be of the same
size as a pointer. But this use is not portable across different
compilers.
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.
nullptr is not a macro, it's a keyword. A warning that flagged any
sentinel that isn't nullptr wouldn't need to look at preprocessor
tokens.
But I think -Wstrict-null-sentinel is better anyway, isn't it?
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.
