This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Make dllimport/dllexport imply default visibility
Andrew Pinski wrote:
> Well this allows for easier violating of ODR. I guess I am just a bit
> off of what is going on here but I agree with Chris in that this
> really should be rejected as you have stuff which is hidden and then
> you call a non hidden member function. How can the vtable be hidden
> while the member functions not be? I think if you try to throw that
> class across boundaries, it will never be caught as the typeinfos are
> different.
There's nothing that says that the class even has a vtable. Or, this
might be a static member function. Obviously, if that function tries to
access the vtable, it will fail to link -- but it might very well not
need to access the hidden stuff.
> So really I think this is just bad pratice and should at least get a
> warning, even though code in real life exists, the code is broken to
> say the least.
I'm not sure why you say that the code is broken. It works. As far as
I know it doesn't violate any specification. What's broken about it?
This is valid:
void f() __attribute__((visibility("hidden")));
void g() __attribute__((dllimport));
void f() { g(); };
So is:
struct S {
void f() __attribute__((visibility("hidden"));
void g() __attribute__((dllimport));
};
void S::f() { S::g(); };
So, why not:
struct S __attribute__((visibility("hidden")) {
void f();
void g() __attribute__((dllimport));
};
void S::f() { S::g(); };
In any case, in practice, ARM's RealView compiler accepts:
struct __declspec(notshared) S {
__declspec(dllimport) void f();
void g();
};
void S::g() {
f();
}
And, there's a large body of code that uses this.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713