Additional memory handler features.

[Niels Möller]

Victor Shoup <shoup at cs.nyu.edu> writes:

> First, it seems to me that Marc's example of custom allocators
> can perhaps best be viewed as a work-around of GMP's lack of
> "proper" error handling.  So one should be careful not to
> conflate error handling with memory management.

Maybe. Nevertheless, I'll focus on the handling of allocation failures
below.

> So let's ignore custom memory allocators for a minute,
> and just think about error handling.
> There are just a few viable approaches:
>   1) abort with error message (current approach)
>   2) return codes (the traditional C approach)
>   3) C++ exceptions
>   4) longjump

My take is that (1) is a reasonable default behaviour. (2) is probably a
too big interface change (even if one realizes that applications using
default allocators, which abort on failure, doesn't need to check the
return values).

As for (3) and (4), I'd prefer to not have gmp make this choice. But
defer to the custom allocation functions (and any other "exception
function pointer" for other types of errors) if it wants to abort, or
longjmp, or raise some type of exception.

I think we should also keep in mind other types of exceptions than those
provided by C++, e.g., guile exceptions or objc exceptions.

I'd strongly prefer if we can define an interface for error handling and
clean up temporary storage which works fine if gmp is compiled as plain
C, and is language agnostic, e.g., based on memory pools. But if that
turns out to be too difficult, I guess it's not too unreasonable to have
proper cleanup on C++ exceptions require that gmp is compiled with a C++
compiler.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.