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

[John Pye]

Hi there,

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 can't use the suggested method from the manual either,

> The library does type checks, range checks, consistency checks at many
> places. When one of these fails, the function |cl_abort()| is called.
> Its default implementation is to perform an |exit(1)|, so you won't
> have a core dump. But for debugging, it is best to set a breakpoint at
> this function:
>   	
>
>(gdb) break cl_abort
>        
>
> When this breakpoint is hit, look at the stack's backtrace:
>   	
>
>(gdb) where
>        
>
because my pre-compiled CLN doesn't seem to have debug symbols:

> [john at jdpipe nla-ginac]$ gdb pipesystem
> GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)

...

> This GDB was configured as "i386-redhat-linux-gnu"...Using host
> libthread_db library "/lib/tls/libthread_db.so.1".
>
> (gdb) break cl_abort
> Function "cl_abort" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (cl_abort) pending.
> (gdb) run
> Starting program: /home/john/nla-ginac/pipesystem
> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0xb7f9f000

...

> floating point NaN occurred.
>
> Program exited with code 01.
> (gdb) where
> No stack.


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

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.

Cheers

JP