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