abort on error - is this being addressed?

[Allan Chandler]

I've been using GMP as a user for a little while now but I just came
across a comment on the web from someone who suggests not using it
because:
    GNU MP unconditionally calls abort() on allocation failures,
    which are bound to happen with certain insanely large
    computations. This is unacceptable behaviour for a library and
    reason enough to write your own arbitrary-precision code.

That was certainly news to me.

Now I don't intend to second-guess why such a decision was made in
the first place and I'm certainly not going to go back to my own
safe, but relatively slow, library (especially since I've never
actually experienced an out-of-memory error in my stuff) but it
appears to me also that this is not optimal behaviour for a library.

Has anyone thought of addressing this issue?

If so, I'd like to know what came of it (or what is currently coming
of it).

If not, I would like to propose a suggestion.

Rather than calling abort if a memory allocation fails, it might be
better to provide an alternative of returning to the caller with some
indication that the operation has failed. Whether this is done by a
return value or via a global error indicator (thread-specific in
threaded environments of course) is one thing to be looked at.

Then, at least, the caller would have the option of deciding what to
do. If they want to abort then, by all means, they should abort. But
I would suggest that they wouldn't want to do this, instead preferring
to notify someone of the problem then continue on as best they can.

Obviously, care needs to be taken here vis a vis memory cleanup. If
you're going to abort anyway, it doesn't matter whetehr you leave
the malloc arena in a dodgy state but, if we are going to allow the
caller to continue, we'd better make sure things are cleaned up.

It seems to me that a phased approach to change would work here. We
could first and foremost make this a compile-time #define thing so
that people still wanting the old behaviour with absolutely no change
to their performance would be satisfied.

We could also make it run-time with a flag of some sort so people
could select whether they want GMP to abort or whether they want a
flag of some description set. This may have performance implications
of continuously checking said flag at multiple levels of the call
stack but, if that's a problem, people should revert to the
fast-but-unsafe code mentioned in the previous paragraph and bear the
possibility of abort.

A phased approach of modifying small parts of GMP would minimise
the chance of damaging the integrity of the code. What I mean by that
is that we just do one section of the code at a time, as long as the
call trees are more trees than bushes. I haven't had a good look at
the code yet so I don't know how tightly integrated it is but it
may be that we could tackle integer stuff (mpz_*) as a unit, then
rationals (mpq_*) and so on.

Does anyone else have any thoughts on this? I'd be interested in
taking on the task myself if need be, at least initially.

Cheers,
Al.