This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Visibility attribute
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Matt Austern <austern at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 26 Nov 2003 11:10:37 -0800
- Subject: Re: Visibility attribute
- References: <FCFC725B-1FD1-11D8-8A76-000393B2ABA2@apple.com>
Matt Austern <austern@apple.com> writes:
> 3. The later declaration always overrides the earlier. So x and z
> have default visibility, y has protected visibility.
...
> Option 3 is what the compiler
> currently does.
As I commented in the bug report, the compiler doesn't currently do it
right; except in unit-at-a-time mode, anything between the
declarations will be compiled assuming the initial visibility.
However, this can only cause trouble in certain cases. As I think HJ
was trying to say, maybe the best choice is an 'option 6':
6. If the later declaration has more restrictive visibility that the
earlier, the later declaration overrides; otherwise, the visibility
from the earlier declaration is used.
So, from your examples,
__attribute__ ((visibility("hidden"))) int x;
int x = 5; // is still 'hidden'
__attribute__ ((visibility("hidden"))) int y;
__attribute__ ((visibility("protected"))) int y = 5;
__attribute__ ((visibility("hidden"))) int z;
__attribute__ ((visibility("default"))) int z = 5;
all three variables end up 'hidden', since that's the most restrictive.
Perhaps a warning when a visibility attribute is explicitly specified
and is ignored; but that's not essential.
--
- Geoffrey Keating <geoffk@geoffk.org>