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

I wrote [for two classes S with visibility == hidden ]
> | > | We can have two distinct
> | > | classes named S, and no one can tell.  Each bit of code will see one
> | > | definition of S.

Jason Merrill <> writes:
> | I think that Joe's point is that IF you have two classes named S, then
> | they're hidden away in separate shared libraries and you can't compare
> | them, because no piece of code knows about both of them.

Yes.  It is sometimes necessary with very large software systems to
use tricks like this because someone was sloppy about naming (particularly
in older code that comes from times before namespaces were universally
available, and many of us do have to deal with 7-10 year old code on

On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
> I'm not clear about "you can't compare them".
> Surely, I can take the address of typeid(S) and pass it around to
> a function in another translation unit.  I can do
> typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
> from two such different translation units.
> How the current visibility framework prevent that from happening?

By a note in the documentation telling the user "don't do that".

I think it's safest just to say that if people want to use hidden
visibility to violate the ODR, and they succeed in getting a pointer to
class S from, and a pointer to the distinct class S from, into the same hunk of code and then try to compare the
typeinfo objects, that we simply don't define what happens.

I think it would be a mistake to try to define the semantics in this

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