Re: [xml] XML library evaluation (fwd)

[Daniel Veillard <veillard redhat com>]

On Thu, Jun 13, 2002 at 03:18:11PM +0100, Dan Ellis wrote:
> The company I work for has been developing C++ software using the libxml2
> library. However, due to memory allocation problems within the library it
> has been decided to drop libxml2 in favour of Xerces. I've suggested that
> they bring these issues up here to see if they're known, and if there are
> any solutions (either existing, or being worked on). This hasn't been
> done, so I'm forwarding some information regarding the evaluation. Are
> these known issues? Can anything be done about them, and if so, will they
> be?
> ---------- Forwarded message ----------
>
> [snip]
>
> Libxml2 evaluation
> The libxml2 library displayed a lot of different errors, both crashes,
> where un-initialised data, null pointers and data that had already been
> freed was accessed. Secondly there here a lot of memory leaks that needed
> to be fixed.

  there is no known memory leak in libxml2. Usually all such reports ends
up being misuse of the library or forgetting to free some document or 
temporary data.
  the absolute lack of information in your report make it useless, it's
a shame, there might be memory leaks, but if it was the case there is no
way to make progresses. This might also be related to the way you encapsulated
libxml2 in C++.

> But the main concern was that the library is written in C and is not
> designed to return an "Out of memory" error code from the calls into the
> library. Instead a variety of different behaviour was seen:

  The memory allocation layer can be completely overriden with custom routines,
maybe reading the doc would help before doing any evaluation, no ?
    http://xmlsoft.org/xmlmem.html#setting

> 1.) Quietly recover, where the processing would simply continue after the
> allocation failure, but some data would be missing in the XML tree that it
> was building. Another problem was that any error, during the libraries
> initialisation would not be reported and hence the whole library would not
> work correctly, for example some character handling functions might not be
> present.

  "Some character handling function might not been present ?" What on earth
does this mean. If you need support for encoding "foo" there is a way to
be 100% sure it's present: provide it and register it.
    http://xmlsoft.org/encoding.html#extend

> 2.) Return an error code, which would not be distinguishable from any other
> error, for example when parsing a document, it is not possible to
> distinguish a parse error from a memory allocation error.

  yes it is, plug your own memory wrapper and catch it there.

> Conclusion
> On balance it seems, barring any problems that A might discover, that
> the following picture emerges:
>
> * Libxml2 - It's general lack of safety and lack of "out of memory" return
> codes make this library unacceptable.

  My conclusion, your evaluation is what it is, if you don't like the code
fine by me, use whatever you want, but I react to bug reports, not to vague
and unsubstanciated assertions about the quality of my code. If you don't
like something, patches are usually looked at and applied if reasonable, that's
the way things work here. You may have a more standard relationship with 
IBM and the Xalan developpers, hope this suits you, have fun !

  have a nice day,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/