From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E48B91F5AE for ; Mon, 26 Apr 2021 19:38:56 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C78B43955413; Mon, 26 Apr 2021 19:38:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C78B43955413 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619465935; bh=sDEhMcr60SMtfkZ1lIT4fjSCMNNcZHaCcxe/0sl++B4=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Bqzd+G/pbAR3HiOmBFLayaObQDGcUsdBaWBCFHZHdDkmWMc4vHYZ9hqyBpB/+8gcD BulROp3GI5dT7hniNaqtzDWv7iWLcrDJUMCg13Mf9P0ogjHZV2IygAK+eUilz3rca9 9M5YtpKUePch2NbdFjLPsBw1aRRqIqZZJl9GRimM= Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id C4A673955404 for ; Mon, 26 Apr 2021 19:38:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C4A673955404 Received: by mail-qt1-x82e.google.com with SMTP id d12so4446488qtr.4 for ; Mon, 26 Apr 2021 12:38:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sDEhMcr60SMtfkZ1lIT4fjSCMNNcZHaCcxe/0sl++B4=; b=MPUrPKYHHgn08sBYFH44OSw6QUJRDLQmTC/ffWF2s5TkNrdEKSrXCY9AhvDdOhkvvD SUn/HEq9nxEWJu70alHafnEoi8AYLZRdzUJuTECYG8izza/XK7ZMMaUJ7Dc4APTIe7ze tNDDprCohFhZ/sQZS9EKwtbCgfxbWVbBGN8xL2vXTvmH7l74Ckgg5/0ZazFuSckNlquG qStgqJUf/HRbA8iLk3V524PJCqvSTL07H9v5Sn5y5CoHSHrAUBTafPlKIqKKSzV84dsF g6o/RqsNOAav90hI4+EXwlI+eNdt1ucupSIx0W6HCBpZYR53ICf0nMXhDPD5HdNZ8k6v nyEg== X-Gm-Message-State: AOAM531PyCRq8w4GYdPr7FU7LdQc9PNcsYA1sIU5SxhuDGk4ipJ1Q3Lr ZeZWt14Xt/fdRVNNNw3Is1IcW0HrgrQ= X-Google-Smtp-Source: ABdhPJzC38PoJBPHPW8qzOuAJrF1YgFowpGwf9N2qX4zL2iZIz2triuMsR6cOAw3P70MKzxxvMiG6w== X-Received: by 2002:aed:306c:: with SMTP id 99mr18035645qte.352.1619465933047; Mon, 26 Apr 2021 12:38:53 -0700 (PDT) Received: from [192.168.0.41] (71-218-14-121.hlrn.qwest.net. [71.218.14.121]) by smtp.gmail.com with ESMTPSA id 97sm12272634qte.20.2021.04.26.12.38.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Apr 2021 12:38:52 -0700 (PDT) Subject: Re: [PATCH] add attribute none to pthread_setspecific (BZ #27714) To: Paul Eggert References: <2ec7fadb-cc15-a005-f708-d2adecc8cc39@gmail.com> <6c23d4f8-9c48-6bf6-ed13-a02ac66bc92b@cs.ucla.edu> <229f6971-f400-f701-7bda-0fbbd3a90c35@cs.ucla.edu> Message-ID: Date: Mon, 26 Apr 2021 13:38:51 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <229f6971-f400-f701-7bda-0fbbd3a90c35@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Martin Sebor via Libc-alpha Reply-To: Martin Sebor Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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