Re: [PATCH] add attribute none to pthread_setspecific (BZ #27714)

[Martin Sebor via Libc-alpha <libc-alpha@sourceware.org>]

On 4/23/21 6:27 PM, Paul Eggert wrote:
> On 4/23/21 2:29 PM, Martin Sebor wrote:
>> GCC doesn't let language conformance modes affect unrelated warnings
>> (like -Wuninitialized) and I am not in favor of introducing such
>> a distinction in Glibc.
> 
> If this is talking about __STRICT_ANSI__, misc/sys/cdefs.h uses that 
> macro already when defining _Static_assert on older compilers. The use 
> is not to avoid unrelated warnings; it's to conform to the relevant 
> standard on request.

I am saying that that introducing a dependency on __STRICT_ANSI__
as you suggested would have the effect of disabling access warnings
when the -ansi option is set and would be a QoI bug/regression and
so is not in my view suitable.

I've tested your suggested change to the __attr_access macro without
the dependency on __STRICT_ANSI__ in all language conformance modes,
both with and without -ansi, both in C and C++, and with all of GCC
9, 10, and 11.  The only diagnostics I saw involving the new
attribute definition were -Wvariadic-macros with GCC 10 in C++ 98
and C++ 11 modes with -Wpedantic and -Wsystem-headers:

../misc/sys/cdefs.h:598:31: warning: anonymous variadic macros were 
introduced in C++11 [-Wvariadic-macros]
   598 | # define __attr_access1(mode, ...) __attr_access##mode (mode, 
__VA_ARGS__)
       |                               ^~~
../misc/sys/cdefs.h:599:38: warning: anonymous variadic macros were 
introduced in C++11 [-Wvariadic-macros]
   599 | # define __attr_access__none__(mode, ...)
       |                                      ^~~
../misc/sys/cdefs.h:600:43: warning: anonymous variadic macros were 
introduced in C++11 [-Wvariadic-macros]
   600 | # define __attr_access__read_only__(mode, ...) \
       |                                           ^~~

My test includes all the standard C headers that use the attribute
(and a few others).

I don't know what Glibc's policy is regarding -Wsystem-headers but
the uses of variadic macros in other Glibc headers show that they
are guarded with #if !__cplusplus, presumably to avoid the same
warnings.  In light of that, I'm not comfortable introducing
the variadic macro in a fix for a false positive when a simpler
fix is available that doesn't trigger other warnings.

If you have a strong desire to redefine the macro in some way
please do it separately of the fix for the false positive.  That
way, if there's any unwelcome fallout, the change can be reverted
without reintroducing the false positive.

I plan to commit my originally proposed patch this week unless there
are objections.

Martin