unavoidable abort in mpz/realloc.c

[Torbjorn Granlund]

Marc Glisse <marc.glisse at inria.fr> writes:

  On Wed, 16 Mar 2011, Torbjorn Granlund wrote:
  
  > OK, so now you vaguely claim, as a bug report, that GMP's check for mpz
  > type overflow is bad, and--if I understand you correctly--that we should
  > fall into the allocation function with a size we cannot represent.
  
  I don't think he necessarily wants to fall into the allocation
  function, all he wants is a way to replace the call to abort in
  mpz_realloc with something the user can override (and he wanted the
  same thing for __gmp_invalid_operation). I think he has a point there.

My reply when this suggestion comes up is that users should catch the
signal thrown by abort.

That's not a great solution, since there is a possibility of memory
leak, since the call chain between the setjmp and the longjmp may have
made permanent allocations.  It might be possible to do something fancy
with custom allocation, but I don't think it will be possible to make
that work under all circumstances.

Yes, this is bad.  This is a major flaw in GMP.

So, now there were suggestions to replace abort calls with a call via a
custom function, which would default to abort.  Granted, this would open
for some granularity improvements (which were not suggested, I think),
i.e., GMP could give some error code to the custom function.  It would
also be a bit cleaner than setting up a signal handler.  But the real
problem still stands.

I'd like to address the main problem, that of unwinding a call chain in
GMP without leaking memory.

Do people agree that setjmp/longjmp is the only mechanism available for
unwinding the call chain?  I am not familiar with -fexceptions.  Does
that allow for some (portable) neater mechanism?

-- 
Torbjörn