[CLN-list] Overriding read_number_bad_syntax on OS X

[Ron Garret]

On May 13, 2007, at 4:55 PM, Bruno Haible wrote:

> Ron Garret wrote:
>
>> An improved version would replace cl_read_number_XXX ...
>
> Indeed, this is what is most in the spirit of how CLN was designed.  
> The doc
> says:
>
>   CLN aims at being easily integrated into larger software packages:
>      * The library provides hooks for memory allocation and  
> exceptions.
>
> The hooks for memory allocation are documented in <cln/malloc.h>,  
> but those
> for the exceptions are not realized in the same way.
>
> I agree with you; the following functions should be realized  
> through hooks
> in the same way:
>    cl_abort
>    cl_error_division_by_0
>    cl_as_error
>    cl_notreached_abort
>    read_number_bad_syntax
>    read_number_eof
>    read_number_junk
>    uninitialized_ring
>    uninitialized_error
>    cl_error_floating_point_nan
>    cl_error_floating_point_overflow
>    cl_error_floating_point_underflow
>    cl_ash_error
>    cl_error_exquo
> possibly even _all_ occurrences of cl_abort.
>

It surprises me to learn that numerical errors abort as well.  I  
conjecture that munging the source code is a common mode of deploying  
CLN in real applications.

> Richard B. Kreckel wrote:
>> I am imagining some Linux distribution where CLN is compiled with
>> -fno-exceptions and a naive user is specifiying cl_reader_error to be
>> called instead of exit. I haven't checked but I'm sure this will  
>> incur
>> undefined behavior: a crash, a memory leak, you name it.
>
> It will be a memory leak. Like when you use longjmp to abort a  
> computation.

Even for parser errors?  It is not a foregone conclusion that  
anything will have been allocated on the heap, and the parser  
routines are standalone, are they not?  i.e. none of the other CLN  
code will ever invoke the parsing code, right?

>> I propose to define a
>> couple of exception classes and throw these instead of calling  
>> cl_abort.
>

That would work for me, however...

>> So, to be safe, the library will have to be compiled with exceptions
>> enabled. But what is the advantage of providing such a callback  
>> then? I
>> don't think anyone will do anything but throw exceptions from it!
>
> Good point.
>
> Just to think a bit further: Assume someone creates a C binding of  
> CLN -
> this is a requirement brought up by RMS (such a thing existed a  
> long time
> ago, but was unfortunately made with a proprietary ILOG tool) - how  
> would
> the exception handling look like? Will it be a longjmp? Will it be  
> a C++
> exception handler?

If it were me, I'd write the wrapper in C++ with functions declared  
extern "C" that catch all exceptions and do something else with  
them.  But that's just me.

I can think of at least two other approaches.  Neither of these would  
be my first choice, but they wouldn't require exceptions:

1.  Return some kind of NaN-like thing when there's an error.

2.  Return an undefined value on error, and have a global (or per- 
thread) flag that gets set when an error occurs.

The second one is inferior from an architectural point of view, but  
is almost certainly easier to implement.

Personally, I strongly prefer exceptions, but that's just because  
they work well for my particular application.

rg