This is the mail archive of the gcc@gcc.gnu.org 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


Joe Buck <Joe.Buck@synopsys.COM> writes:

> 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?
> 
> Joe Buck <Joe.Buck@synopsys.COM> writes:
> > > By a note in the documentation telling the user "don't do that".
> 
> On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote:
> > No, there's no such note.  The answer is that the two typeids have
> > different addresses, so one will be before the other, depending on
> > where the shared libraries got loaded, just as if the classes had
> > different names.
> 
> We're in complete agreement.  What I meant was to say that if Gaby is
> worried over user confusion on this point, we'd add a warning that
> the result isn't defined, but I expressed it in a sloppy way.  I know
> that the documentation currently says nothing on the matter.

Oh, I see.

The definition for 'before' in the standard says

> true if *this precedes rhs in the implementation's collation order.

and 'collation order' is not-specified as:

> The names, encoding rule, and collating sequence for types are all
> unspecified and may differ between programs.

I guess we could say that even for the same binary, the collating
sequence still might differ between runs of the binary (on systems
like Linux where the library load addresses vary randomly); or you
could just try to fit that under the definition of a 'program'.

However, this is not a visibility-related issue, since the exact same
thing happens even if you don't use any visibility control at all, and
just have two differently-named classes in different shared objects.


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