Re: Feature request: optionally compile with support for exceptions

Roberto Bagnara bagnara@cs.unipr.it writes:
Not only I expect all allocations that may fail to be done through the custom allocation functions; I also expect GMP not to leave inconsistent objects around in case of allocation failures. And it would also be very desirable that no memory is leaked in that cases (this is harder to achieve and can be left as a desideratum).
I'm also a little confused. There are at least two ways to do it: Either have the allocation functions return NULL, and then the GMP functions allocating memory must check for that and set gmp_error to GMP_ALLOCATE. But from my reading of the source (e.g. mpz/init.c), there are no such checks. (In fact, it seems gmp_errno is only ever set by the randomness functions. And I wouldn't miss it if it was purged from the code; using global variables for error reporting is ugly).
The other alternative is to expect the allocation function to longjmp out on failure (and C++ exceptions is about the same thing, from GMP:s point of view). Then GMP has to be careful not to leak any memory when such jumps happen.
/Niels

nisse@lysator.liu.se (Niels Möller) writes:
There are at least two ways to do it: Either have the allocation functions return NULL, and then the GMP functions allocating memory must check for that and set gmp_error to GMP_ALLOCATE. But from my reading of the source (e.g. mpz/init.c), there are no such checks.
That's so. The allocate functions must succeed, or die trying. :-)
(In fact, it seems gmp_errno is only ever set by the randomness functions. And I wouldn't miss it if it was purged from the code; using global variables for error reporting is ugly).
A rather unfortunate design. Something better for exception reporting has been on the todo list for some time, but nothing has come of it yet.
The other alternative is to expect the allocation function to longjmp out on failure (and C++ exceptions is about the same thing, from GMP:s point of view). Then GMP has to be careful not to leak any memory when such jumps happen.
Presently longjumps or exceptions will, in various circumstances, leak memory and perhaps leave mpz_t etc variables in inconsistent states. The fact this is unsupported will be clarified in the doco.
Regards -fexceptions, I was actually about to go the other direction and declare all the C functions as "throw()", ie. never throwing exceptions. But this would close off the possibility of future support for C++ exceptions out of the allocate functions, or elsewhere, so might not be a good idea just yet.
I guess any support for exceptions depends on all the internals being ready to clean up after themselves, or keeping themselves clean in the first place. That looks like quite a bit of work, and unlikely to happen soon.
participants (2)
-
Kevin Ryde
-
nisse@lysator.liu.se