abort on error - is this being addressed?

[Allan Chandler]

The main problem with using signals is that you don't get a chance to clean
up memory allocations in the intervening stack levels and that there are
precious few things you can actually do in a signal handler.

My whole point with the suggestions was that you could configure GMP to act
in exactly the same way as it currently does, aborting if you run out of
memory. Or you could ignore the global/thread-specific "ran-out-of-memory"
flag (at your peril) or you could choose to handle it.

I wasn't proposing to change all the function prototypes to return errors
that *had* to be checked, just wanted a way that it could be checked if an
application wants to use it but not have the rug pulled out from underneath
it. It's not the library that should be making the decision what to do if a
calculation can't be done.

If the mpz_mul in your below example cannot alloc memory, it should, in my
far-from-humble opinion, clean up any memory it's allocated for the job,
set the error flag then just return (NULL).  If the client sees fit to
ignore that, tough luck.

Original message below:
=====
The allocation functions can be customised, see the GMP manual.  Any
fancy behaviour can be impelemeted by the user, including ordering more
swap disks, reclaming memory by GC or compaction, or killing of other
processes.

Running out of memory is a condition which is difficult to handle.
Assume we have this sequence of GMP calls,

  mpz_add (...)
  mpz_mul (...)
  mpz_add (...)

and the mpz_mul cannot store its result due to memory shortage.  What
should GMP do?  Store it anyway...?  Store some other value that fits in
memory...?

GMP calls abort which on Unix systems means a SIGABRT is sent to the
process.  This can be caught using the standard POSIX signal mechanism.
If we had designed GMP to use return codes, we could have used that,
resulting in ugly user programs:

  if (mpz_add (...) == ERROR)
     ...
  if (mpz_mul (...) == ERROR)
     ...
  if (mpz_add (...) == ERROR)
     ...

I think this would be much worse than using signals.
=====