https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #3)
> What is interesting is that VRP info already shows that this cannot be zero:
>
> # RANGE [0, 9223372036854775805] NONZERO 9223372036854775807
No, bits set in NONZERO bitmask are "may be nonzero", not must be nonzero.
Bits clear in that bitmask are "must be zero". So NONZERO 9223372036854775807
just says that the most significant bit is clear, nothing else.
(In reply to Andres Freund from comment #2)
> Maybe (In reply to Jonathan Wakely from comment #1)
> > The first XLogRegisterData could change the value of xl_xinfo.xid to be
> > non-zero, in which case the second XLogRegisterData call would happen
> > despite the null string.
>
> Well, that'd then still only be a ok for a "may be" warning, not one that
> say "argument 1 null where" (i.e. without a may be). Also, XLogRegisterData
> here takes a const char * argument, so it really shouldn't modify the
> argument?
For most of the warnings, we don't have "may be" and "is" variants, and while
we do have it for -W*uninitialized, the boundary isn't that clear. The warning
on the #c0 is IMHO desirable, whenever that strlen is called, it will be with
NULL argument, and the compiler can't prove (because the other call that takes
the address of the info stuff) the call will not be called with the NULL
argument ever. For -W*uninitialized, we call "is" if the uninitialized use
happens always if the function is called, no exception is thrown or calls on
the path to the statement never return, and "may be" otherwise. Even the "is"
are "may be", it all depends on that the function is called at all and that the
code is actually reached.
