From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by sourceware.org (Postfix) with ESMTPS id D6E783858C78; Tue, 1 Mar 2022 11:22:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D6E783858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodji@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id 1864D40003; Tue, 1 Mar 2022 11:22:42 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 675DA5802B4; Tue, 1 Mar 2022 12:22:42 +0100 (CET) From: Dodji Seketeli To: gprocida at google dot com via Libabigail Cc: gprocida at google dot com Subject: Re: [Bug default/28319] abidw - regression in treatment of anonymous enums in structs Organization: Me, myself and I References: X-Operating-System: Fedora 36 X-URL: http://www.seketeli.net/~dodji Date: Tue, 01 Mar 2022 12:22:42 +0100 In-Reply-To: (gprocida at google dot com via Libabigail's message of "Mon, 24 Jan 2022 17:06:17 +0000") Message-ID: <878rttkjct.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 01 Mar 2022 11:22:46 -0000 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 the= re 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. [...] > 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? Thanks. --=20 Dodji