error handling

[Victor Shoup]

Just wanted to check back on this...

I'm getting closer to my quixotic goal of making NTL exception safe.
As NTL can be (optionally) compiled to use GMP for long integer arithmetic,
the error handling of GMP is the remaining issue (for that compilation mode).
Note that for NTL, only a handful of mpn-level routines are used,
and most of these (presumably) don't do any memory allocation
or abort for any other reason (except for things like mpn_mul and a few 
other things).

I know there might be some progress on this, but I was also wondering 
about a more short term workaround. I found somewhere the following rough idea:
  - override GMP's default memory allocation routines, so that
    extant GMP allocations are recorded (on a per-thread basis).
    [Note: For my use, these would only be temp allocations made by mpn-level
    routines]
  - if memory allocation fails, throw an exception
  - in the C++ client, provide logic (via RIAA, presumably) that will
    clean up any extant GMP memory allocations

In addition, one would have to compile GMP under gcc using -fexceptions.

This should work, I guess, under some assumptions:
  - GMP does not hold on to any memory between calls to mpn routines
  - there is no other "global state" that would be messed up by 
    an exception passing through mpn-level routines

In addition, one would also have to assume that GMP does not abort
the program for any other reasons...I'm not sure about this....I know that 
there are some places where GMP checks for limb counts that are too big,
but I doubt that NTL would run into those, as it make its own checks
for such things outside of GMP, and only calls fairly low-level mpn routines
(I think mul, div, gcd, and sqrt are the most "high level", but I could compile
a complete list, if that would help).

I guess a more generally helpful solution would be to have GMP allow
a user "error callback function", which could be used in the above solution
outline to throw an exception.  But as far as I know, GMP does not 
provide this functionality.

Any comments on any of the above?

I've tried to initiate a discussion with the Sage developers about workarounds
that they know about, as they use both GMP and NTL, but I figured I should
check back here, as well.

Thanks!!



On Nov 10, 2014, at 1:43 PM, Marc Glisse wrote:

> On Mon, 10 Nov 2014, Victor Shoup wrote:
> 
>> I know that this subject has come up before, but I was wondering if there
>> are any updates.
> 
> Not that I know :-(
> 
>> I maintain a C++ library (NTL) that uses GMP for long integer arithmetic.
>> While NTL itself currently has very primitive error handling (print to stderr and abort),
>> I'm investigating the possibility of making it use exceptions that client code could
>> potentially deal with.  One obsticle to this is GMP's error handling.
>> In my particular situation, NTL only uses GMP at the mpn layer, so much of
>> the memory management is done by NTL (although I presume even the mpn
>> layer of GMP needs to allocate memory for temporaries).
>> 
>> So I'm wondering if there is any hope in the future of GMP offering
>> alternative error handling strategy?  I know that GMP is "pure C",
>> but perhaps it could nevertheless be updated so that with judicious
>> use of macros, it could be compiled as a C++ library that would
>> throw exceptions in an appropriate manner.
> 
> Being able to compile GMP as C++ is officially a goal, at least for testing purposes so we can more easily experiment with unusual limb sizes.
> 
> Note that you can already tell GMP to use your allocator, which can throw exceptions, and if gmp was compiled with gcc -fexceptions, they will propagate. Some memory will leak in that case though.
> 
> I am still planning to implement the second paragraph of this message:
> https://gmplib.org/list-archives/gmp-devel/2012-February/002210.html
> but as you can guess from the date you shouldn't hold your breath...
> Though it is simple enough that I may do it this winter.
> 
> -- 
> Marc Glisse