Re: [Libvir] RFC: safer memory allocation APIs with compile time checking

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. 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. So maybe taking a hint from all the languages that contain 'fat' runtimes isn't the worst of strategies: die loudly by default, and let the application specify other handlers. In practice, the usefulness of those handlers is limited by their inability to unwind the stack and free dead memory on the way out. Has anybody seen such handlers be useful short of a full exception implementation ?

David [1] http://log.ometer.com/2008-02.html#4