On Mon, Apr 28, 2008 at 06:45:54PM +0000, David Lutterkort wrote:
On Mon, 2008-04-28 at 13:38 +0100, Richard W.M. Jones wrote:
> On Mon, Apr 28, 2008 at 03:39:41AM -0400, Daniel Veillard wrote:
> > Calling abort() in a library is a major NO-NO and one of the reasons
> > I avoided glib in most of the code I developped. You just can't
exit()/abort()
> > from a library.
>
> That depends ... If you can override the abort() function with an
> error handler, then I'd say it is OK.
I used to not think very highly of calling abort() by default, but
reading Havoc's blog post about that a while ago[1] is making me doubt
conventional wisdom. He cites libxml2 as one example where OOM leads to
crashes - I take that not as an indication that there is something wrong
with libxml2, but with the approach of checking and correctly handling
all allocation failures.
It's a matter of testing, Havoc looked at it some years ago, but now
the Huawei people (embedded/telecom) are chasing the behaviour on OOM
systematically. Of course the more dynamic and complex the data structures
are the harder it is, and XML tree processing is on the hard side
unfortunately.
Allocation failure happens very rarely, and testing it properly is
near
impossible; allocation failures amount to an additional input stream
that is read deep down in the call hierarchy and can generally not be
checked by the caller like other arguments.
you can, you do fault injection, testing systematically each allocation
done during a test run, computationally expensive for sure, but doable,
it's being done...
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/