From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD5823858C60; Tue, 1 Mar 2022 14:56:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD5823858C60 From: "gprocida at google dot com" To: libabigail@sourceware.org Subject: [Bug default/28319] abidw - regression in treatment of anonymous enums in structs Date: Tue, 01 Mar 2022 14:56:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gprocida at google dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 01 Mar 2022 14:56:55 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28319 --- Comment #16 from gprocida at google dot com --- Hello. On Tue, 1 Mar 2022 at 11:22, dodji at seketeli dot org wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D28319 > > --- Comment #15 from dodji at seketeli dot org --- > gprocida at google dot com via Libabigail a > =C3=A9crit: > > > Hi Dodji. > > Hey Giuliano, > > > git grep use_enum_binary_only_equality > > Now, from what I am seeing, that one is not used anywhere anymore. The > last use of it was in an obsolete comment. I removed it in this commit > https://sourceware.org/pipermail/libabigail/2022q1/004184.html. > > [...] > > > > When I tested in comment 12, I looked for changes in abidw output and t= here was > > none. > > > > There is a regression in abidiff though. > > > > The two enums in these small code fragments > > > > enum E6 { a6 =3D 6 } v6; > > > > enum E6 { a6 =3D 6, b6 =3D 6 } v6; > > > > are treated as ABI equivalent ... > > Yes, this is as intended. In the function > equals(const enum_type_decl& l, const enum_type_decl& r, change_kind* k) > in abi-ir.cc, you can see the comment: > > // Now compare the enumerators. Note that the order of declaration > // of enumerators should not matter in the comparison. > // > // Also if an enumerator value is redundant, that shouldn't impact > // the comparison. > // > // In that case, note that the two enums below are considered equal: > // > // enum foo > // { > // e0 =3D 0; > // e1 =3D 1; > // e2 =3D 2; > // }; > // > // enum foo > // { > // e0 =3D 0; > // e1 =3D 1; > // e2 =3D 2; > // e_added =3D 1; // <-- this value is redundant with the value > // // of the enumerator e1. > // }; > // > // These two enums are considered equal. > > > ... as they share the same set of enumerator values. > > It's rather because they have the same enumerator names /and/ values, > modulo one /additional/ enumerator which value is redundant with the > existing ones. So in this newer way of seeing things, the previous > concept of "binary-only equality" is not used anymore. > enum E6 { a6 =3D 6 } v6; vs enum E6 { a6 =3D 6, b6 =3D 6 } v6; Well, the sets of enumerator values are: { 6 } vs { 6 } and the sets of enumerator names are: { a6 } vs { a6, b6 } So they don't have the same enumerator names. As you point out, the addition of "b6" does not change the meaning of any other enumerator. I think we understand each other. It's just a question as to whether this should be considered an ABI difference. Perhaps it should be a "harmless" difference, though I would not want to add more complexity to code that is not regularly exercised in production. I also discovered recently the concept of C (and this does not exist in C++) type compatibility. https://en.cppreference.com/w/c/language/type#Compatible_types https://www.ibm.com/docs/en/zos/2.1.0?topic=3Dtypes-compatibility-structure= s-unions-enumerations-c-only These documents could be more clear, but I think they imply that these two are compatible. enum E { b =3D 2, a =3D 1 }; enum E { a =3D 1, b =3D 2 }; On first reading, I thought cppreference also implied that these two are compatible (which would be relevant here), but I don't think they are: enum E { a =3D 1, b =3D 2 }; enum E { a =3D 1 }; > [...] > > > 2. Just for the record, if you think this is working as intended, please > > re-close the bug. > > Yes, I think it's working as intended. I'll wait for you to double > check if you see an obvious issue. If not, I'll let you close the bug. > Would that work for you? > Sure. > Thanks. > > -- > You are receiving this mail because: > You reported the bug. --=20 You are receiving this mail because: You are on the CC list for the bug.=