From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BD0123858005; Mon, 6 Dec 2021 13:54:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD0123858005 From: "dodji at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/28073] [libabigail] Incorrect size for bitfields Date: Mon, 06 Dec 2021 13:54:07 +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: dodji at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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: Mon, 06 Dec 2021 13:54:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28073 dodji at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from dodji at redhat dot com --- I think the correct suppression specification for this should be: 1/ [suppress_type] name =3D bigstruct has_data_member_inserted_between =3D {offset_of(bitfield0), offset_of(other)} Why? because offset_after(bitfield0) means the offset of the data member that co= mes after bitfiled0, in the initial version of the type. In that version, the = data member that comes after the data member "bitfield0" is the data member "oth= er". So, {offset_after(bitfield0), offset_of(other)} is equivalent to: {offset_of(other), offset_of(other)}. And that is not what we want. The code that evaluates the suppression specification, however, has a tangentially related flaw: If bitfield0 is later removed, the suppression specification 1/ should not suppress that removal change. That flaw is now fixed by the commit https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcommit;h=3D3e0eeb9f98216= ecd1c3224f687fe1e1ef72b56e4 which also updates the documentation of to clarify the use of the has_data_member_inserted_between property. --=20 You are receiving this mail because: You are on the CC list for the bug.=