[Bug default/28289] [1.7 -> 1.8 regression] false positives involving enum synthetic type names

["gprocida at google dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28289

--- Comment #4 from gprocida at google dot com ---
The problem that the commit mentioned addressed could have been addressed in at
least one other way (by changing the hashing used for enum types and reordering
type elements keying by hash).

The treatment of underlying enum type by DWARF and libabigail is a bit uneven.
I don't think there's any requirement for DWARF to give a name (such as "int")
to the underlying type. The most important aspect is size. However, in C++, the
exact type can be user-specified and can impact overloading resolution /
implicit conversions to some degree (say bool vs int).

The commit, like other changes over the last year, resulted in changes to the
ABI representation for the same input. As you point out, the name change
triggers abidiff. In post-1.8 development the (first, partial) bitfield offset
fix warranted an XML version bump, making abidiff refuse to compare mismatched
XML files, but no such thing was done for the 1.7->1.8 changes.

In theory, abidiff could be tweaked to ignore underlying type name when it
comes to C enums; in practice this may not be straightforward. I'm not actually
sure what the treatment of C++ enums is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.