_mp_alloc vs ALLOC

[Torbjorn Granlund]

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
type.

  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
  clutter.

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.

-- 
Torbjörn