Re: gcc visibility used by moz

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Geoffrey Keating <geoffk@apple.com> writes:

| Jason Merrill <jason@redhat.com> writes:
| 
| > Gabriel Dos Reis wrote:
| > > Jason Merrill <jason@redhat.com> writes:
| > > So, -concretely- what happens to a class S (e.g. associated type
| > > info object
| > > address, address of member functions, etc.) with external linkage,
| > > defined in multiple translation units, with say hidden visibility?
| > 
| > If it has hidden visibility then shared objects other than the one
| > with the definition can't do much with it.  They can use inline
| > interfaces and interfaces that are explicitly overridden to have
| > default visibility.
| > 
| > Anything that relies on weak symbols to unify vague linkage entities
| > across shared objects will break.
| 
| I don't think "break" is the right word here.  It will behave exactly
| as documented.  If you were expecting the two classes to be the same,
| then you'll find won't be, but this is not breakage, it is a fault of
| your expectation---and remember, we have a perfectly good way to make
| sure that the classes *are* the same, which is to give the classes
| default visibility.

I believe I did not communicate correctly the issue.  Consider the
(other version of)
current definiton of type_info::before:

    #if !__GXX_MERGED_TYPEINFO_NAMES

    bool
    type_info::before (const type_info &arg) const
    {
      return __builtin_strcmp (name (), arg.name ()) < 0;
    }

    #endif


This implementation will make the expression

    !typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)

holds for two such classes that you consider different.  That is
inconsistent. 

-- Gaby