Re: Minimal GCC/Linux shared lib + EH bug example

[martin at v dot loewis dot de (Martin v. Loewis)]

"David Abrahams" <david.abrahams@rcn.com> writes:

> No, I'm saying that I'm relying on being *allowed* to use them, and I don't
> happen to care whether they're shared in this case. 

Well, the "restrictions" document would say "you can use these
features, but we don't guarantee any specific semantics".

This is the same for the exception handling: you can certainly throw
any exceptions you want - but the compiler (or run-time system) won't
guarantee that you can catch them everywhere.

How could the authors of the compiler, or the authors of Python, know
which deviations from accepted well-defined behaviour (in this case,
the ISO C++ standard) are acceptable to you, and which aren't?

What good would be it be if you are happy, but the next user complains
that all his counters are incorrect? (apart from the fact that I want
you happy, of course :-)

> > Also, how do you think you can initialize the static template member?
> > Through function calls of the class template? Forget it, that might
> > not work - you are relying here on functions being emitted together
> > with the instantiation of the static member, and there is no guarantee
> > that this will work.
> 
> 
> I have no idea what the above might mean. I do not happen to be calling the
> class template's own function members to initialize its data, but I can't
> imagine how it would be a problem unless I were relying on sharing or
> not-sharing... But I'm not.

Your get_x function above would fail to work if it was a member of the
template, since you can multiple copies of the block-static variable.

Likewise, if the get_x function is implemented in a static library, it
will fail to work correctly - even if it is defined the way you wrote
it.

> These /are/ susceptible to the same sort of workaround, using references
> (an extra level of indirection, the classic approach!) I wouldn't expect to
> see a unique copy unless all instantiating libraries share symbols globally
> with one-another.

I think with RTLD_LAZY, you are up for even more surprises, e.g. when
the local variable and its initialization guard resolve inconsistently.

Regards,
Martin