[CLN-list] Overriding read_number_bad_syntax on OS X

Bruno Haible bruno at clisp.org
Sat May 12 14:48:02 CEST 2007


Hello,

Ron Garret [ex-Erann Gat] wrote:
> A few years back I wrote a little app that uses cln on Linux.  I had  
> to override the behavior of read_number_bad_syntax and  
> read_number_junk so that the app wouldn't quit whenever there was a  
> syntax error.  I accomplished that with the following code:
> 
> namespace cln {
>    void read_number_bad_syntax(const char * string, const char *  
> string_limit) {
>      throw 0;
>    }
>    void read_number_junk (const char * string_rest, const char * string,
>                           const char* string_limit) {
>      throw 0;
>    }
> }
> 
> This worked on Linux.  I am trying to port the code now to OS X 10.4  
> and it doesn't work.  The code compiles just fine, but when I run it  
> any syntax error invokes the built-in behavior

Shared libraries in ELF (like on Linux) and shared libraries on MacOS X
work differently.

Static libraries work the same. Therefore one solution to your problem is
to build CLN as a static library. The resulting executable will then have
to be relinked when you upgrade to a new CLN version. But since the executable
will only contain _your_ version of read_number_junk, not CLN's original
function of the same name, the problem will not occur in this case.

Shared libraries on MacOS X work as described in
  http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html
  http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html
In section "Symbol exporting strategies" they mention a compiler option:
"gcc -weak_library". I would try this option when building CLN as a shared
library.

> BTW, is there a reason that the default behavior is to quit rather  
> than throw an exception?

When CLN was written, exceptions were not a mature specification nor
technology: rethrowing an exception was undefined behaviour, and
g++ created huge code when used without "-fno-exceptions". This has probably
changed meanwhile...

Bruno



More information about the CLN-list mailing list