possible extension to --harmless: changes to trailing enumerator (MAX/bounds) values

[Nick Alcock]

So I just upgraded nss. It's a very, very ABI-stable library: nothing
changes with it. But my routine abidiff (2.5) run (with --no-added-syms
--no-unreferenced-symbols --leaf-changes-only --impacted-interfaces
--debug-info-dir1 ... --debug-info-dir2 ...) shows "ABI changes":

'enum SECOidTag at secoidt.h:34:1' changed:
  type size hasn't changed
  2 enumerator insertions:
    'SECOidTag::SEC_OID_X25519' value '388'
    'SECOidTag::SEC_OID_MLKEM768X25519' value '389'
  1 enumerator change:
    'SECOidTag::SEC_OID_TOTAL' from value '388' to '390' at secoidt.h:34:1
  18 impacted interfaces:
    function SECOidTag HASH_GetHMACOidTagByHashOidTag_Util(SECOidTag)
[...]
'enum SECOidTag at secoidt.h:34:1' changed:
  type size hasn't changed
  2 enumerator insertions:
    'SECOidTag::SEC_OID_X25519' value '388'
    'SECOidTag::SEC_OID_MLKEM768X25519' value '389'
  1 enumerator change:
    'SECOidTag::SEC_OID_TOTAL' from value '388' to '390' at secoidt.h:34:1
  150 impacted interfaces:
    function PK11SymKey* NSS_CMSContentInfo_GetBulkKey(NSSCMSContentInfo*)
[...]

This is not a real ABI change. The additions would already be ignored by
--harmless, except that SEC_OID_TOTAL has been bumped. This is as
harmless as these things get, the updating of a bound, routine in
ABI-stable libraries, and it would actually be a bug to *not* update it.
There is no sense in which it's an ABI change, even if one considers
enum values to be part of the ABI in the first place (and if one does,
why not #define values?)

I see this everywhere: KDE, nss, even xlib (a library with an ABI as
stable as any) have been hit with this. The number of false positives I
see from this one case outnumbers all the real reports of unexpected ABI
breaks I see by about an order of magnitude.

The question is how on earth to fix it. Heuristics involving
regex-matches on the name for TOTAL and MAX and the like are obviously
too disgusting to consider!

It might work to use a different heuristic though: to ignore increases
in value of the highest-value enumerator in an enum when that increase
is specifically equal to the number of enumerators added to the enum.
That'll handle cases where it's a count of enumerators, but not cases
where the range has holes in it and some of the additions fill in the
holes (not contributing to a MAX increase). This might be enough to
solve most cases.