https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #8 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #7)
> Both for the purposes of the warning (which can be more restrictive than
> what the language considers valid), and in the C language, the semantics of
> the -> expression depend on the first operand designating an object. In C
> they're defined like so:
>
> A postfix expression followed by the -> operator and an identifier
> designates a member of a structure or union object. The value is that of
> the named member of the object to which the first expression points, and is
> an lvalue. 106)
While gcc 12 has meanwhile been released, it's still not clear how we could at
least work around this (mis-)diagnostic, _without_ simplifying the conditional
expression (which, as said, actually is the result of macro expansion, and the
macro should not be open-coded [and then simplified] here).
It's also not just an issue with the underlining in the diagnostic - the
overall expression !() as well as the conditional expression on its own isn't
"always true" or "always false". It's only the 2nd operand of the ternary
expression which is, but that's not on its own used in boolean context.
Otherwise why would
if(ps ? (void*)1 : (void*)0)
not result in a similar warning? And note that while
if(ps ? &ps[10] : (void*)0)
does,
if(ps ? &(&ps[10])[-10] : (void*)0)
again doesn't, while from &ps[10] being non-NULL (pointing at or one past a
valid object) it imo ought to follow that &(&ps[10])[-10] is also necessarily
non-NULL.
Note further that if the two array indexes don't sum up to 0, the offset
reported in the diagnostic also looks to be wrong - it appears to lack division
by sizeof(*ps).
