From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id CDCF83828930; Fri, 27 May 2022 09:36:22 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDCF83828930
From: "jbeulich at suse dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/102967] confusing location in -Waddress for a subexpression
 of a ternary expression
Date: Fri, 27 May 2022 09:36:22 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jbeulich at suse dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102967-4-p1vpiGkeIb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102967-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102967-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2022 09:36:22 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102967

--- 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:
>=20
>   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 conditio=
nal
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 necessari=
ly
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 divi=
sion
by sizeof(*ps).=