Re: abi-compliance-checker

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> I tried comparing REL_11_0 to REL_11_20. Attached is the report for that.

Nice!

> I don't have time to study this in detail today, but the report seems
> to have a plausible variety of issues. I noticed that it warns about
> the breaking signature change to _bt_pagedel(). This is the
> theoretical ABI break that I mentioned in the commit message of commit
> b0229f26. This is arguably a false positive, since the tool doesn't
> understand my reasoning about why it's okay in this particular
> instance (namely "any extension that called that function was already
> severely broken"). Obviously the tool couldn't possibly be expected to
> know better in these kinds of situations, though, so whether or not it
> counts as a false positive is just semantics.

Agreed. The point of such a tool is to make sure that we notice
any ABI breaks; it can't be expected to make engineering judgments
about whether the alternatives are worse. For instance, I see that
it noticed commit 1f28ec6be (Rename rbtree.c functions to use "rbt"
prefix not "rb" prefix), which is not something we would have done
of our own choosing, but on balance it seemed the best solution.

I gather it'd catch things like NodeTag enum assignments changing,
which is something we really need to have a check for.

(Which reminds me that I forgot to turn on the ad-hoc check for
that in gen_node_support.pl. I'll go do that, but it'd be better
to have a more general-purpose solution.)

regards, tom lane