_mp_alloc vs ALLOC

Torbjorn Granlund tg at gmplib.org
Mon Jun 4 22:50:17 CEST 2012

nisse at lysator.liu.se (Niels Möller) writes:

  Torbjorn Granlund <tg at gmplib.org> writes:
  > I know of only two C mechanims, either signals+handlers or setjmp+
  > longjmp.
  I'm not entirely sure what type of errors you are considering handling
  here? Memory allocation failures? Divide-by-zero? Something else?
Those things, and similar.  Even-root-of-negative and other ops that are
either undefined, or whose Im fall outside of the destination operand

  It's possible to make errno-style handling thread safe by using some of
  the available mechanisms for putting errno into thread local storage
  (pointer to current exception handler would likewise also have to live
  in thread-local storage). But it's not particularly pretty.
Nothing lite this is pretty in C.  But we could provide the
setjmp/longjmp and errno as options.

  Returning a success/failure from each call, and manually propagating the
  error up the call tree (and doing any needed cleanup un the way) seems
  to be the sanest way to do error handling in C. Even if it's a lot of

The cleanup is what worries me most.  It might be prone to errors, it
might slow things down, and it might be alot of clutter.

  If you do something like exceptions with setjmp/longjmp, I think you'd
  also need something like unwind-protect to ensure that you cleanup
  temporary allocations and the like, and that appears a bit brittle to me
  (but I'm not sure I'd trust the automatic stack unwinding with C++
  exceptions either...).
I think our TMP mechanism will help here.  It is either alloca, which
will be unwound by longjmp, or it is a stack over which we have control.


More information about the gmp-devel mailing list