_mp_alloc vs ALLOC
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+
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++
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