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).

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>

1 files changed, 2 insertions, 2 deletions

diff --git a/xmlsave.c b/xmlsave.c
index f7173ebb..bf805330 100644
--- a/xmlsave.c
+++ b/xmlsave.c
@@ -2186,9 +2186,9 @@ xmlAttrSerializeTxtContent(xmlBufferPtr buf, xmlDocPtr doc,
  *
  * Dump an XML node, recursive behaviour,children are printed too.
  * Note that @format = 1 provide node indenting only if xmlIndentTreeOutput = 1
- * or xmlKeepBlanksDefault(0) was called
+ * or xmlKeepBlanksDefault(0) was called.
  * Since this is using xmlBuffer structures it is limited to 2GB and somehow
- * deprecated, use xmlBufNodeDump() instead.
+ * deprecated, use xmlNodeDumpOutput() instead.
  *
  * Returns the number of bytes written to the buffer or -1 in case of error
  */