[CLN-list] Overriding read_number_bad_syntax on OS X

[Bruno Haible]

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.

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.

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

> 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?

Bruno