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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list