https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The analyzer will be hopefully improved for GCC 16, there was just a minimal
support added so that the analyzer tests didn't regress.
The normal -Wnonnull warning actually uses range information already, so it the
range suggests that the size can't be zero and NULL is passed, there is a
warning emitted.
As for actual optimizations, there is a patch in the work to use the range
information, see
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676805.html
And lastly, far more important than warnings is the runtime sanitization which
is a reliable way to find (certain kinds) of UB in programs and that handles
this attribute and the builtins correctly, checks at runtime actually that if
the corresponding size argument is non-zero and the pointer is NULL that there
is UB that should be diagnosed.
(In reply to Alejandro Colomar from comment #2)
> I've been trying to convince Joseph, Aaron, and the C Committee that it was
> a terrible mistake to allow a null pointer here, precisely for this worry,
> and it seems my worries were correct.
I strongly disagree with this, I think the change was highly desirable.
