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
