Re: RFC: Make dllimport/dllexport imply default visibility

[Bill Wendling <wendling at apple dot com>]

On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:

> Bill Wendling wrote:
> > 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.
Okay. What I mentioned was based on the docs for 4.0.1 where it says:

"On Microsoft Windows and Symbian OS targets, the dllimport attribute  
causes the compiler to reference a function or variable via a global  
pointer to a pointer that is set up by the DLL exporting the symbol."

So my thoughts were, "because a hidden structure could still have a  
pointer which points to global data, then this should be okay." But  
the scenario you described is clearly bad.

-bw