No "forwarding" of memory handler functions to libexpat

[Sacryn]

When creating the parser context, the memory functions set when creating the xmpp-context is not forwarded to libexpat. This causes libexpat to use regular malloc/realloc/free instead, which is a issue in projects where you must use custom allocators.

I realize problematic to solve, as memory functions are xmpp-context dependent. But maybe implementing a way to set a global memory functions (more or less a configurable default xmpp_mem_t) could solve this (which would then be forwarded to libexpat via calling XML_ParserCreate_MM instead of XML_ParserCreateNS)

[pasis]

Good catch. The same situation with libxml2 module. I don't see any acceptable solution with current interface neither.

I wouldn't recommend to add a global state to libstrophe. Global allocator would require locking for multi-thread applications for example.

Removing argument userdata allows to pass libstorphe's allocator to expat and libxml2, but this also breaks user allocators that don't use global state.

I will think what we can do in this situation...

[pasis]

Since I don't see perfect solution I would recommend to remove userdata argument from the libstrophe's API. Users still can implement multi-thread allocators of any complexity and libstrophe's code remains simple and without internal locking.

I made a quick search for openssl custom allocator, but haven't found anything. Anyway playing with crypto library is not a good idea.

Are you interested in preparing the patch? Or I can implement this.

[Sacryn]

Feel free to implement/patch. I'm a bit swamped at the moment otherwise I would be happy to help out.

[pasis]

No problem, I'll do this at spare time.

[pasis]

fb327d4 fixes the issue for a single strophe context. Libxml2 module still doesn't override memory functions.