abort on error - is this being addressed?

[Marc Glisse]

On Thu, 26 Aug 2010, Allan Chandler wrote:

>    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.

First, notice that any OS that overcommits memory (like Linux unless you 
use some option that is not recommended) makes the point moot.

> Has anyone thought of addressing this issue?

It is mentionned in the projects.html file ;-)

> 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.

mpn is the obvious place to start.


On Thu, 26 Aug 2010, Niels Möller wrote:

> 1. Have an alternative set of functions where the caller must allocate
>   and provide space not only for the result, but also any temporary
>   scratch space needed during the computation. Search this list for
>   itch/scratch for more info. Some of the low-level functions are
>   already written this way, but a lot of work remains.

It looks like the approach with the best chances of success in a not 
too distant future.

> 2. Register your own allocation functions with GMP, which detect
>   allocation failures. Then, set up a allocation marker and a setjmp
>   buffer before each computation which might exhaust memory. On
>   failure, have the allocation function not return to gmp, instead, it
>   should deallocate all temporary storage (using the above "marker"),
>   and longjmp out to abort the computation.

C++ does have some good points...

-- 
Marc Glisse