This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc visibility used by moz

Geoffrey Keating <> writes:

| Jason Merrill <> writes:
| > Gabriel Dos Reis wrote:
| > > Jason Merrill <> 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:


    type_info::before (const type_info &arg) const
      return __builtin_strcmp (name (), ()) < 0;


This implementation will make the expression

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

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

-- Gaby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]