On Dec 1, 2005, [EMAIL PROTECTED] (Geoffrey Keating) wrote:
> The 'weakref' attribute is defined in terms of aliases. Now,
> if the user writes
> void foo(void) { }
> void bar(void) __attribute__((alias ("foo")));
> then that causes 'bar' to be defined. Other translation units can use
> 'bar'. If 'weakref' is to define an alias, it should behave the same
> way.
weakref does not define an alias. It defines a weakref. It happens
to use some of GCC's aliasing machinery under the covers, but that's
all. It's not an alias like non-weakref aliases, anyway.
> The easiest solution to this is to require that weakrefs must be
> 'static', because the name that they define is not visible outside
> this translation unit.
While this is true, not all properties of static names hold for
weakrefs. If the name they refer to is not itself static, none of the
local-binding analysis properties will apply correctly if the wekaref
is marked as static. I felt it was safer to keep it extern.
> * doc/extend.texi (Function Attributes): Mention that an alias
> attribute creates a definition for the thing it's attached to.
Except for weakrefs, that may introduce a local (weakref) definition,
if the assembler supports .weakref, or no definition whatsoever, if it
does not.
> Change the documentation for weakref to say that the thing
> it's attached to must be static.
Err... The above is a bit misleading, in that it at first appeared to
be referring to the target of the weakref, not to the weakref itself.
The weakref may alias to something that is static or not (the whole
point is being able to refer to symbols in other translation units
with weak and non-weak semantics). The weakref itself could be static
or extern, and both possibilities could be argued for and match
certain uses. Since attribute alias has traditionally required the
extern keyword, I figured it would make sense to keep it as such, but
if you prefer to change that and adjust all cases in which the use of
static might cause problems, that's certainly fine with me. I don't
see that you're taking care of such cases, though.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
