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