[CLN-list] Overriding read_number_bad_syntax on OS X

[Richard B. Kreckel]

Hi!

On 2007-05-12 22:33 CEST, Ron Garret wrote:
> On May 12, 2007, at 1:11 PM, Richard B. Kreckel wrote:
> 
>> Well, it depends on your point of view. I was referring to the  entire read_number_bad_syntax function as a form of "user- specifiable callback".  :-)
> 
> 
> Except that it isn't user-specifiable and it isn't a callback.  Other  than that there's no problem.


Ron, what happened to your sense of humor? Overriding the function is 
certainly user-specifiable and the entire thing is kind of a "callback" 
if you are willing to accept that the function to call is specified at 
link time rather than at run time. That's why I was putting double 
quotes and a smile there. But never mind.   :-/


On 2007-05-13 22:01 CEST Ron Garret wrote:
> OK, here's a minimalist version.  It only changes cl_abort.cc:
> 
> namespace cln {
> 
> void (*cl_abort_hook)(int) = exit;
> 
> void cl_abort (void)
> {
>   cl_abort_hook(1);
> }
> 
> }  // namespace cln
> 
> I have tested this on OS X with the following client code:
> 
> namespace cln {
>   extern void (*cl_abort_hook)(int);
>   void cl_reader_error(int status) { throw status; }
> }
> 
> and it works.  I have not tested in on Linux, but I have no reason to  
> believe it would behave any differently there.
 >
> An improved version would replace cl_read_number_XXX with functions  
> that assembled the error message as a string instead of outputting it  
> to cerr, and calling cl_abort_hook with that string, with a default  
> cl_abort_hook that printed the string to cerr and then called exit,  but 
> I thought I'd start with the smaller version just to test the  waters.


This may solve your problem but, in practice, how useful is it? 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.

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!

But then it will be better to throw well-specified exceptions directly.

The real question that I would like to see answered is how much overhead 
is incurred by exceptions. If it is negligible, I propose to define a 
couple of exception classes and throw these instead of calling cl_abort. 
The exception classes could be subtypes of std::runtime_error, because 
catching these is frequently used as a last resort.

Let's have a look at the overhead before deciding on an interface.


> This patch is small enough that it probably doesn't matter, but for  
> future reference, what is the preferred format for submitting  patches? 
> diff?  diff -e?  diff -n?  Can I send a darcs patch?


Any diff with context such that I can apply it using patch is fine.

Best
   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>