Anything specific I should check?Hum, all entry points which may generate such a parser context wrapper object and similary anything which may destroy one. Nothing specific in mind, but for example a reader instance embed a parser context at the C level and while there is no API to export it that may be added at some point, it seems your suggestion would cover this fine, but taht need checking.
This is only remotely related but I've noticed that htmlFreeParserCtxt is exposed. That may cause some troubles because the free is already done in parserCtxt.__del__.
Ok. That will be later this week.
Here it is, with a test case. A few things worth noting: - xmlFreeParserCtxt is not autogenerated anymore because it needs to free _private (added to libxml.c, and to generator.py:skip_function). This has the side effect that parserCtxt.freeParserCtxt is not there anymore; it can be readded, but I fear a double free problem, like for htmlFreeParserCtxt above. - initialization of _private is done in libxml_xmlParserCtxtPtrWrap. - I've added a parserCtxtCore base class to parserCtxt to hold registerErrorHandler and registerWarningHandler (because I could not find a way to autogenerate them). - I've factored out a libxml_buildMessage from libxml_xmlErrorFuncHandler. -sbi
Attachment:
ctxerror.patch
Description: Binary data
Attachment:
ctxterror.py
Description: Text document