This is the mail archive of the
mailing list for the GCC project.
Re: gcc visibility used by moz
- From: Jason Merrill <jason at redhat dot com>
- To: Benjamin Smedberg <benjamin at smedbergs dot us>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 11 Jul 2006 17:46:02 -0400
- Subject: Re: gcc visibility used by moz
- References: <44B412CC.firstname.lastname@example.org>
Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:>
Take the following code:
class __attribute__ ((visibility ("hidden"))) HiddenBaseClass
__attribute__ ((visibility ("default"))) HiddenBaseClass*
This declaration warns "CreateAClass() declared with greater visibility
than its type. And when CreateAClass is instantiated, it is hidden
This seriously breaks XPCOM, which uses this model throughout our code
(default-visibility accessors for interface types, which are declared
with hidden visibility). Why should this model be prevented?
A similar issue is present for hidden-visibility classes with
default-visibility member functions:
class __attribute__ ((visibility ("hidden"))) HiddenClass
__attribute__ ((visibility ("default"))) void SomeMethod();
I see that you explicitly wrote your patch to disallow this kind of
declaration, but I can't figure out why: it works, and we were using it.
This is a less serious issue in that we only use this pattern in a few
places and we can replace the exported method with a non-class method
fairly easily, but I can't take that change on the mozilla 1.8 or 1.8.0
branch. So, unless these patterns can be made to work, it seems that
FF1.5 and 2 are going to both be thoroughly broken when compiled against
It seems that you have a different mental model of type visibility. The
way I was thinking about it, if a type has hidden visibility, we can't
refer to it from outside its object. Thus, it doesn't make sense for
members or objects with that type to have greater visibility because
even if people can call the accessor they can't do anything with the
However, I'm not attached to this in defiance of practical concerns.
What is your model of type visibility?