[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