On 10/24/2018 11:27 AM, Joseph Myers wrote:
> On Wed, 24 Oct 2018, Martin Sebor wrote:
>
>> On 10/24/2018 06:22 AM, Joseph Myers wrote:
>>> On Wed, 24 Oct 2018, Martin Sebor wrote:
>>>
>>>> But if you do want to avoid the attribute on declarations of
>>>> these functions regardless it should be safe to add it after
>>>> the declaration in the .c file, like so:
>>>>
>>>> __hidden_ver1 (strcmp, __GI_strcmp, __redirect_strcmp)
>>>>   __attribute__ ((visibility ("hidden"), copy (strcmp)));
>>>
>>> The obvious question there is whether the glibc patch should use copy
>>> (local) as well as copy (name) in the definition of __hidden_ver1.
>>
>> I tried copy(local) but it breaks where local isn't declared.
>> I think errno_location was the first one I saw where it referred
>> to __GI__something_or_other that was previously only defined via
>> an asm.
>
> In that case maybe it should go in the .c files (the patch should define
> some common attribute_copy macro in some internal header, to avoid lots of
> places needing to duplicate conditionals for whether it's supported).

I defined __attribute_copy__ in cdefs.h like other attributes
and used it in libc-symbols.h and in the string .c files but
it turns out that cdefs.h isn't always included when the
libc-symbols.h macros are used.  For instance,
sysdeps/unix/sysv/linux/umount.c is compiled without it which
results in errors.  So the way I worked around it pretty hacky.
Attached is what I have.  I'm sure there's a better way that
you will want to adopt for Glibc but this works as a proof of
concept and results in no warnings by default.  With
-Wattribute-alias=2 it gives the attached warnings for aliases
with more restrictive attributes than their targets (alloc_size,
const, leaf, malloc, nonnull, noreturn, nothrow, pure, and
returns_nonnull).

The GCC patch is the same so please let me know if there's
something to change there.

>
> Whether nonnull attributes should be disabled when building glibc is a
> separate question which would involve reviewing lots of functions with
> such attributes against
> <https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointers>
> to see whether there are checks for NULL that are actually appropriate
> under current glibc conventions but might be optimized away given such
> attributes.  So it should clearly be kept separate from fixes to use copy
> attributes to get better attribute consistency fot aliases.

Agreed.  I certainly don't plan to undertake this project as
part of the GCC attribute enhancement.

Martin