Skip to content

Doc: do not mislead towards "infeasible" scenario wrt. xmlBufNodeDump

At least when merely public API is to be leveraged, one cannot use xmlBufCreate function that would otherwise be a clear fit, and relying on some invariants wrt. how some other struct fields will get initialized along the construction/filling such parent struct and (ab)using that instead does not appear clever, either.

Hence, instruct people what's the Right Thing for the moment, that is, make them use xmlNodeDumpOutput instead (together with likewise public xmlAllocOutputBuffer).

Going forward, it's questionable what do with xmlBuf* family of functions that are once public, since they, for any practical purpose, cannot be used by the library clients (that's how I've run into this).

Merge request reports