Geoffrey Keating wrote:
> GCC's concept of visibility is very different to that of some other
> compilers.
Yes, and that may be a problem. For some features, we want to have GNU
semantics that are consistent that across platforms; for others, we want
to match other compilers on a particular platform.
To be clear, I don't have any objection to the semantics you stated,
from the point of view of first principles of language design. But,
they do not match existing practice on various systems -- and I consider
that a serious problem. In particular, ARM SymbianOS is a system that
has specifically defined DLL attributes in terms of ELF visibility.
There's no choice about the semantics on that system, including the fact
that the first "S" below is a valid class on that system.
Fortunately, for:
> In respect of this specific example, the compiler should not give any
> effect to the attribute on 'f' in:
>
> struct __attribute__((visibility("hidden"))) S {
> void f() __attribute__((visibility("default")));
> }
>
> because another shared library can define:
>
> struct __attribute__((visibility("default"))) S {
> void f();
> }
we can be generous. In particular, we can do what the user asks with
the first "S", i.e., give "f" default visibility. There's no inherent
problem there. We can then detect that there are two "S::f" when both
shared libraries are loaded (if we think that's a useful check), or we
can just call it undefined behavior, as it would be if there were no
visibility markers in this example, but there were conflicting
definitions of "S::f".
We could of course issue a warning, or, I guess, an error. I see this
as a style issue, so a warning seems better to me, but if Darwin wants
to forbid giving member functions more visibility than their containing
classes, that's not for me to say.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
