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