* Petr Pisar: > Well abidiff for createrepo_c > <https://artifacts.dev.testing-farm.io/3a97fed7-84b8-4220-9a7b-9f988dd8cd90/work-rpminspectud7bmqxi/rpminspect/execute/data/guest/default-0/rpminspect-1/data/viewer.html> > complains: > > underlying type 'xmlParserCtxt*' changed: > in pointed to type 'typedef xmlParserCtxt' at tree.h:40:1: > underlying type 'struct _xmlParserCtxt' at parser.h:181:1 > changed: > type size changed from 3840 to 3968 (in bits) > 4 data member insertions: > 'unsigned int maxAmpl', at offset 3840 (in bits) at > parser.h:323:1 > 'xmlParserNsData* nsdb', at offset 3872 (in bits) at > parser.h:325:1 > 'unsigned int attrHashMax', at offset 3904 (in bits) at > parser.h:326:1 > 'xmlAttrHashBucket* attrHash', at offset 3936 (in bits) at > parser.h:327:1 > 1 data member changes (5 filtered): > type of 'int* attallocs' changed: > in pointed to type 'int': > type name changed from 'int' to 'unsigned int' > type size hasn't changed > > While most (all?) libxml2 functions pass a pointer to xmlParserCtxt, a > definition of the xmlParserCtxt structure is open to anybody in > <libxml/parser.h>. That means an application built against old libxml2 can > construct a different structure than libxml2 expects. That is called > an ABI breakage.
I don't think the API allows you to bring your own xmlParserCtxt object (stack-allocated or heap-allocated). The new members are added at the end, so this is probably fine. Thanks, Florian -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
