[PPL-devel] Re: Feature request: optionally compile with support for exceptions

Kevin Ryde user42 at zip.com.au
Wed Oct 24 02:06:21 CEST 2001


nisse at 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.



More information about the PPL-devel mailing list