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


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
{
public:
  virtual SomeMethod();
};

__attribute__ ((visibility ("default"))) HiddenBaseClass*
CreateAClass();

This declaration warns "CreateAClass() declared with greater visibility than its type. And when CreateAClass is instantiated, it is hidden visibility.

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 gcc trunk->4.2

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 return value.


However, I'm not attached to this in defiance of practical concerns. What is your model of type visibility?

Jason


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