Re: RFC: Make dllimport/dllexport imply default visibility

[Mark Mitchell <mark at codesourcery dot com>]

Bill Wendling wrote:
> On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
> 
>> Consider:
>>
>>  struct __attribute__((vsibility ("hidden"))) S {
>>    void __declspec(dllimport) f();
>>  };
>>
>> At present, we give "f" hidden visibility.  That seems odd since the
>> user has explicitly told us that the symbol is coming from another
>> shared library.
>>
>> I'm planning to make any dllimport or dllexport attribute imply default
>> visibility.  Is that a bad idea?
>>
> Perhaps I'm mistaken, but the above seems to indicate to me that the
> structure (and, therefore, all of its fields) are hidden, one of its
> functions is from an external and visible source.

Yes.  And, therefore, emitting a undefined reference to S::f with hidden
linkage in the current translation unit causes S::f to have hidden
visibility in the shared object containing this translation unit.  For
example, if the translation unit goes on to say:

  void g() {
    S s;
    s.f();
  }

we will now have an undefined reference to S::f with hidden visibility.
 As a result, S::f will have hidden visibility in the shared object
containing this translation unit.  Thus, despite dllimport, the user
cannot actually import a function of a hidden class from another DLL.

That seems bad.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713