From: "dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: libabigail@sourceware.org
Subject: [Bug default/26591] New: detect pathologically redundant types in abixml
Date: Wed, 09 Sep 2020 15:18:30 +0000 [thread overview]
Message-ID: <bug-26591-9487@http.sourceware.org/bugzilla/> (raw)
https://sourceware.org/bugzilla/show_bug.cgi?id=26591
Bug ID: 26591
Summary: detect pathologically redundant types in abixml
Product: libabigail
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: default
Assignee: dodji at redhat dot com
Reporter: dodji at redhat dot com
CC: libabigail at sourceware dot org
Target Milestone: ---
In general, a current version of libabigail tries hard to de-duplicate types.
As a result, the idea is that abixml file have non-duplicated types.
This means that in theory, type ids as specified by the value of the attribute
id="type-id-xxxx" should be defined only once in the abixml file.
But then that is the theory.
In practice, there are cases where two types can have the same ID. That
usually involves a sub-type.
For instance, sub-ranges of arrays are sub-types that are always part of array
types in C and C++ (In Ada, though, they can be a type on their own). So
sub-ranges are duplicated in practice, but then I don't think that's a problem.
Another valid instance of duplicated type is when there are declaration-only
types, in C++, which have different member types. For instance, a type Foo
might be declared in a header file with a member type Bar0; then in another
header file, Foo might be declared again with another member type Bar1. So
just to be able to define Bar0 and Bar1 in the abixml, we need to show declare
Foo twice, with the same type id.
In C++, I am guessing that the other "fair" case of duplicated ID would be
violations of the "One Definition Rule", because libabigail doesn't detect
these.
All other cases (included those listed here) of duplicated type IDs should be
detected so that they can be either documented or be flagged as being symptoms
a problem related to type comparison in libabigail.
--
You are receiving this mail because:
You are on the CC list for the bug.
next reply other threads:[~2020-09-09 15:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 15:18 dodji at redhat dot com [this message]
2020-09-09 15:18 ` [Bug default/26591] " dodji at redhat dot com
2020-09-10 13:56 ` dodji at redhat dot com
2021-03-02 15:31 ` gprocida+abigail at google dot com
2021-03-05 16:58 ` gprocida+abigail at google dot com
2021-03-05 17:09 ` gprocida+abigail at google dot com
2021-03-05 17:15 ` gprocida+abigail at google dot com
2021-03-20 10:32 ` gprocida+abigail at google dot com
2021-03-31 16:40 ` gprocida+abigail at google dot com
2021-04-06 20:56 ` gprocida+abigail at google dot com
2021-04-06 21:24 ` gprocida+abigail at google dot com
2021-08-12 22:09 ` gprocida at google dot com
2021-12-01 10:19 ` maennich at android dot com
2021-12-03 9:38 ` mark at klomp dot org
2021-12-03 10:25 ` gprocida at google dot com
2022-07-08 11:13 ` gprocida at google dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-26591-9487@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libabigail@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).