From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by sourceware.org (Postfix) with ESMTPS id 7FCAA3861838 for ; Tue, 4 Aug 2020 17:16:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FCAA3861838 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dodji@seketeli.org X-Originating-IP: 91.166.131.130 Received: from localhost (91-166-131-130.subs.proxad.net [91.166.131.130]) (Authenticated sender: dodji@seketeli.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id ABFB2C0006; Tue, 4 Aug 2020 17:16:09 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 6255918008D0; Tue, 4 Aug 2020 19:16:08 +0200 (CEST) From: Dodji Seketeli To: Giuliano Procida Cc: libabigail@sourceware.org, kernel-team@android.com, Matthias =?utf-8?Q?M=C3=A4nnich?= Subject: Re: [RFC PATCH 1/1] Fix decl_base comparison function Organization: Me, myself and I References: <20200722110736.2550361-1-gprocida@google.com> <20200722110736.2550361-2-gprocida@google.com> <87pn86e9fw.fsf@seketeli.org> X-Operating-System: Red Hat Enterprise Linux Workstation 7.8 Beta X-URL: http://www.seketeli.net/~dodji Date: Tue, 04 Aug 2020 19:16:08 +0200 In-Reply-To: (Giuliano Procida's message of "Tue, 4 Aug 2020 16:47:00 +0100") Message-ID: <87d046e3hj.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 17:16:13 -0000 Giuliano Procida a =C3=A9crit: > I'd like to check my understanding of something. [...] > I thought we could rely on their names (at least as a sufficient condition > for inequality). Here are 3 examples. > > 1. In plain C, there's a flat namespace. > > struct { int x; } a; > struct { int x; } b; > > At a language level the types of a and b are distinct and it's illegal to > assign one to the other. > > error: incompatible types when assigning to type =E2=80=98struct =E2=80=99 from > type =E2=80=98struct =E2=80=99 > > They are structurally the same but if we were treat them as identical then > we'd get somewhat misleading diffs when the code gets changed to: > > struct { int x; } a; > struct { long x; } b; If both a and b are global variables (if they are part of the ABI) and we have the change you are referring to, then I don't think it would be misleading to report that change, would it be? The layout of the type of 'b' changed in a way that would warrant a review, at very least, I would believe. More generaly, what you are referring to is language-level type equality. And that is potentially different from ABI-level equality, I would say. I'd say that from an ABI standpoint, the initial types of 'a' and 'b' are compatible and can be used interchangeably. > > [The compiler has to track the identity of these types separately which is > probably easy enough, but we have a few choices of how to refer to the > type: a) file, line, column (which is a bit fragile), b) with reference to > the entities being given a type, which could be a typedef, c) where they > appear in their scope, whatever that may mean.] In other words, we (post DWARF) cannot infer that the two tapes are equal or different based on naming, as by definition, they are anonymous. And they are structurally equal as you said earlier. So yes, from an ABI standpoint, both types are equal by construction. There are cases, though, were we chose (in libabigail) to be closer to the language-level meaning of equality, but anonymous types is precisely one of those cases where we chose to stick more to the binary (or layout) way of seeing things. > > 2. In C++, we get namespace and type name scopes. > > struct A { struct { int x; } a; struct { int x; } b; }; > > error: no match for =E2=80=98operator=3D=E2=80=99 (operand types are =E2= =80=98A::=E2=80=99 > and =E2=80=98A::=E2=80=99) > > It's illegal to assign A::a to A::b as their types are distinct. > > [It's possible to propagate the type's identity to other declarations with > decltype (and auto).] Agreed. the same holds here. > > 3. > > struct A { struct { int x; } a; }; > struct B { struct { int x; } a; }; > > Similarly, A::a and B::a have distinct types. > > error: no match for =E2=80=98operator=3D=E2=80=99 (operand types are =E2= =80=98A::=E2=80=99 > and =E2=80=98B::=E2=80=99) > > This last case is what I thought I was addressing with that TODO. And from a language-centric point of view, you are right. There are also cases cases like that where the type of 'a' could become hidden inside an anonymous namespace. Because the two types are still binary compatible, if they are anonymous we chose knowingly to consider their binary-oriented view of things. Where does this bias come from? It was from a class of application (network related) where they'd use a number of anonymous struct etc to read network data all around. They were more interested in the layout of the type than on its /name/ per se. And that does make sense, from an ABI point of view, I think. If you don't want to name things, then their name probably doesn't really matter. If it does, well, we'll find out structurally. > Let me know if we are talking at cross-purposes. No, I think I understood what you meant. Thank you for taking the time to clarify. Cheers, --=20 Dodji