Patch to allow more granular aborting.

[Niels Möller]

Theo Schlossnagle <jesus at omniti.com> writes:

> Currently, libgmp treats out-of-memory and FPE errors as the same type
> of abort as consistency issues.  This makes it hard to integrate into
> long running processes where you want to catch and react to these
> errors.

I don't quite understand the need. Maybe it would help if you explain
what kind of reaction you are thinking about.

1. About out-of-memory.

Can you explain why the current interface doesn't suffice? You can
provide your own allocation function, and make them raise an error in
any way you please on failure, instead of returning NULL to the caller.

2. And this patch, for __gmp_invalid_operation

--- a/invalid.c	Sat Mar 12 22:38:49 2011 +0100
+++ b/invalid.c	Sun Mar 13 17:50:40 2011 -0400
@@ -68,5 +68,5 @@
 __gmp_invalid_operation (void)
 {
   raise (SIGFPE);
-  abort ();
+  __gmp_internal_abort ();
 }

I would expect that raise (SIGFPE) never returns, and view the abort
call as a sanity check in case that signal is ignored for some reason.
At least I have some difficulty imagining how to write a handler for
this signal that can return in any useful way. Using signals at all has
some drawbacks, but if we keep that (like you do in your patch),
wouldn't it be easier to install a signal handler which does what you
want and doesn't return, than to let the signal handler return to GMP
and then have GMP call your gmp_internal_abort_code function pointer?

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.

/Niels

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