[TRE-general] Weird bug

[skaller]

On Mon, 2006-05-15 at 10:53 +0300, Ville Laurikari wrote:
> On Mon, May 15, 2006 at 05:19:37PM +1000, skaller wrote:
> > But clearly this can happen because that is precisely
> > what does happen when TRE is being linked. Some symbols
> > are coming from TRE and some from the C library.
> 
> Sure, but you get 100% of the symbols from libtre, i.e. you get a
> consistent set of regex symbols.  Right?

Within one module yes. It's possible to link both with shared libs:
X links to tre and Y to gnu, A links to X and Y and passes data
between them without needing to link to either tre or gnu.

Of course this is really the same bug in disguise -- Y forgot
to force tre.

None of this can happen in C++ code in this case due to
typesafe linkage (assuming one has #included the right header file :)

> For ABI compatibility with the system regex functions you need to
> configure TRE with --enable-system-abi.  The compatibility is not
> perfect.  

I don't see how it can work: how do you handle the compiled 
regex struct?

>  Luckily, applications like this are rare.

Also it doesn't matter for Felix, since all the applications
are new, and the desire is a simply for a good regex interpreter.
TRE just happens to be the only one that convinces me (because
the algorithm is backed by research results). The Posix compat
is a small boost -- saves me writing custom documentation :)

> When TRE is built with this flag, you can do
>   LD_PRELOAD=libtre.so some-program

.. on Unix systems. For better or worse whilst I develop in
linux, most interest in advanced languages seems to be
in the Windows world. Maybe because Windows programmers
are in greater need of something decent .. or maybe just
because there are more of them ;(

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net