[xml] XML library evaluation (fwd)
- From: Dan Ellis <dan isvara net>
- To: xml gnome org
- Subject: [xml] XML library evaluation (fwd)
- Date: Thu, 13 Jun 2002 15:18:11 +0100 (BST)
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.
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:
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.
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.
[snip]
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.
* Xerces - While it has some disadvantages, mainly it's side and lacking
some features that we would want, most notably serialization as part of the
library and the ability to validate the DOM tree, it is overall the safest
option and has XMLSchema support, which none of the other do.
[snip]
--
Dan Ellis <dan isvara net>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]