[CLN-list] Overriding read_number_bad_syntax on OS X

[Ron Garret]

On May 13, 2007, at 3:42 PM, Richard B. Kreckel wrote:

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

I had a sense of humor?  ;-)

> Overriding the function is certainly user-specifiable

It is?  How?

> 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.   :-/

Sorry to be a killjoy, but I think I'm genuinely missing something  
here.  Overriding the behavior of these functions at link time would  
be perfectly fine with me, but the whole point of my original posting  
is that on OS X it doesn't seem to work (unless you recompile the  
library, but I think it would be worthwhile to get this to work with  
a standard installation).

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

Sounds reasonable to me.  Empirically I can tell you that it doesn't  
crash.  It might, however, result in a memory leak.  I haven't tested  
that.  (To be clear, my libcln is built using the default settings,  
which I presume means it was built with -fno-exceptions.)

rg