[CLN-list] Options for FP errors in CLN?

[Richard B. Kreckel]

Dear John,

On Thu, 28 Jul 2005, John Pye wrote:
> I've been doing a lot of work with GiNaC recently but just now I think I
> have a problem which relates more specifically with CLN, so hopefully
> I'm asking this question in the right place.
>
> I have had a few problems now with CLN's error handling: it tends to
> just abort when something goes wrong. Is there a reason why it doesn't
> just throw exceptions that I can catch?
>
> >void cl_error_floating_point_nan (void)
> >{
> >	fprint(std::cerr, "floating point NaN occurred.\n");
> >	cl_abort();
> >}
> >
> >
> I can see that I could rewrite the 'cl_abort' function so that it does
> throw exceptions, but I just wanted to point out that CLN is a big job
> to compile and it might be nice if it gives this sort of functionality
> out-of-the-box.

I've also become somewhat unsatisfied with that scheme, lately.  But I
haven't found the time to dig into this.  Question: What exactly
happens when you throw an exception from within a library that was
compiled with -fno-exceptions?

> I can't use the suggested method from the manual either,
[...]
> because my pre-compiled CLN doesn't seem to have debug symbols:

Of course not: when I last compiled it with -g the size of the library
exceeded 64MB.  I'm not enthusiastic about shipping precompiled lib of
this size.

> So, I'd like to suggest replacing cl_abort with either a SIGFPE or a
> standard exception of some sort.

I don't see how SIGFPE would help you with the "no stack" problem.  And
before compiling it with exceptions I would be interested in the overhead
this incurs, especially in the stack unwinding code that comes with dtors.

> But please, if there are other issues at hand, or reasons why you don't
> do things that way, I'd be keen to know.

The list of reasons above is complete, I think.

Regards
  -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>