abi-compliance-checker
От | Peter Geoghegan |
---|---|
Тема | abi-compliance-checker |
Дата | |
Msg-id | CAH2-Wzk7tvgLXzOZ8a22aF-gmO5gHojWTYRvAk5ZgOvTrcEQeg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: abi-compliance-checker
Re: abi-compliance-checker |
Список | pgsql-hackers |
Attached is a html report that was generated by a tool called abi-compliance-checker/abi-dumper [1][2] (by using "abi-compliance-checker -l libTest ... ") . I deliberately introduced 2 ABI compatibility issues affecting postgres, just to see what the tool had to say about it. The first ABI issue I mocked up involved a breaking change to the signature of a function with external linkage. Sure enough, this issue (in CheckForSerializableConflictIn(), as it happens) appears in the report as a medium severity item. The second ABI issue I mocked up involved "filling-in" a hole in a struct (a struct that appears in a header that could be included by an extension) with a new field. In other words, the "put new field in existing alignment padding" trick. This kind of difference is generally believed to be non-breaking, and so is acceptable in point releases. But the issue still appears as a low severity item in the report. The report points out (quite reasonably) that my newly added field won't be initialized by old code. In most cases this will be fine, of course. It's just not something that should be taken for granted. Overall, I like the report format -- especially its severity scale. So it seems like abi-compliance-checker has the potential to become a standard release management tool for Postgres point releases. I can imagine a community resource along the lines of https://coverage.postgresql.org; an automatically generated archive of theoretical/actual x86_64 ABI breaks in each point release. I'd appreciate having greater visibility into these issues. [1] https://github.com/lvc/abi-dumper [2] https://manpages.debian.org/unstable/abi-dumper/abi-dumper.1.en.html -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: