On 2/5/20 1:13 PM, Martin Sebor wrote:
On 2/4/20 6:05 PM, Martin Sebor wrote:
GCC diagnoses declarations of function aliases whose type doesn't
match that of the target (ditto for attribute weakref). It doesn't
yet diagnose such incompatbilities for variable aliases but that's
just an oversight that I will try to remember to correct in GCC 11.
The attached patch updates the manual to make it clear that
aliases must have the same type as their targets, or the behavior
is undefined (and may be diagnosed).
On further review I noticed a few problems with the documentation
of attribute weakref. The manual says that
Without a target, given as an argument to weakref or to alias,
weakref is equivalent to weak.
At present, a declaration to which weakref is attached can only
However, GCC accepts the following declaration:
extern int x (void) __attribute__ ((weakref));
so the second sentence isn't correct without qualification (unlike
weakref, a weak declaration must be external).
Another documentation problem is with the example in the manual that
says that this declaration:
static int x() __attribute__ ((weakref ("y")));
/* is equivalent to... */
static int x() __attribute__ ((weak, weakref, alias ("y")));
but GCC rejects the latter with
error: weak declaration of ‘x’ must be public
Changing the latter from static to extern changes the error to
error: ‘weakref’ symbol ‘x’ must have static linkage
So clearly two declarations with the two sets of attributes are not
equivalent, either extern or static.
I've fixed up these documentation problems in the attached revision
of the original patch. I also mention that besides their types
having to match, the alias must have the same size and alignment
as the target.
PS I also noted that when the function is then also used GCC issues:
warning: ‘weakref’ attribute should be accompanied with an ‘alias’
This matches what the manual says in "Without arguments, it should
be accompanied by an alias attribute naming the target symbol."
But when the weakref function is not used there is no warning.
That seems like an unfortunate side-effect of the choice of issuing
the warning a little too late (waning from the front-end it would
make it consistent regardless of whether the function was used, and
it would highlight the omission even in translation units that
define the weakref without using it).