Additional memory handler features.

[Vincent Lefevre]

On 2015-01-04 11:41:02 -0500, Victor Shoup wrote:
> 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
> 
> Approach (2) would require changes to the current interface.
> For functions that currently return void, one could just make them
> return int, and so this would be a fairly minor change.
> But there are presumably some functions that already return
> a non-void value, and so this would not work for such functions.
> Another issue is that clients would now have to constantly
> check these return codes -- failure to do so is even worse
> than approach (1).

An alternate approach to (2) would be to have objects (mpz_t, mpq_t,
mpf_t...) that can contain "error" values. For the usual arithmetic
operations, the clients would not really need to do any check since
error values would propagate. This would be a bit like NaN for
floating-point values (except that the error would not come from the
values of the arguments, but from limitations of the environment).
Of course, the clients would need to be careful with operations that
cannot propagate the error (comparisons, some conversions...).

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)