https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
--- Comment #6 from Alejandro Colomar <alx at kernel dot org> ---
(In reply to Jakub Jelinek from comment #5)
> They should. It is more important not to force UB on cases where there is
> no harm (i.e. runtime memcpy (NULL, NULL, 0) and similar) than to get some
> extra warnings in rare cases.
Would it be possible to disable optimizations based on nullability from these
APIs, but otherwise treat nonnull_if_nonzero *exactly* the same as nonnull as
far as diagnostics and -fanalyzer are concerned?
> Runtime sanitization is not a safety net, it detects cases which static
> analyzers can't detect even in theory. Without LTO, static analyzers see
> just a single TU, even with LTO they see just a single binary or library and
> not the whole program, and for compile time and memory reasons they can't
> analyze all possible paths from main anyway, only a couple of callers at a
> time. And the common case with pointers or integers is that analyzers just
> don't know if they could be NULL or not (or could be 0 or not). They warn
> about obvious cases where it is proven that it would likely be NULL in some
> path, but analyzers can't just warn on each int foo (int *p) { return *p; }
> that p could be NULL when they really don't know it could be, that would be
> so many false positives that nobody would use it.
My suggestion to the committee was to wait until _Optional is standardized,
which would put nullability into the type system (like const correctness), and
then this could all be diagnosed at compile time. But they rushed the change.
