Patch to allow more granular aborting.

[Niels Möller]

Theo Schlossnagle <jesus at omniti.com> writes:

> If you know, for a fact, that all failed allocations are termination
> worthy -- I could do this instead.

After a look in the documentation, I see that the allocation functions
are expected to never return NULL. That's why the default functions
(which you patched) call abort on failure, rather than returning NULL.

> I can't do what I want from a signal handler, it isn't safe to throw
> an exception there as we'd be in an alternate stack (most likely).

There are things like sigsetjmp, but I'm not sure how safe that is or
how it reallly works. 

I agree that providing using a callback function seems more robust than
catching the signal. But then, I think it would make sense to invoke
that callback instead of (or at least before) raising SIGFPE signal.

>> 3. The final (I think) case is the mpz_t overflow conditions. Not sure
>> how to get there without first running out of memory, though.
>
> This is the case I was hitting. It was an overflow condition that
> manifested as an OOM.

I'm not following you here. If you run out of memory first, the overflow
conditions (in mpz/realloc.c) will never happen. They could happen,
e.g., if you have two operands of size close to the limit which do fit
in memory, and try to compute their product, of a size which exceeds the
limit.

/nisse

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.