From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by sourceware.org (Postfix) with ESMTPS id 03A8F394342D for ; Fri, 23 Apr 2021 15:24:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 03A8F394342D Received: by mail-qk1-x72a.google.com with SMTP id 8so16199707qkv.8 for ; Fri, 23 Apr 2021 08:24:51 -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=6s+DOR3jWt8/lTY79T/0SnEUtepeq4l9ArH8H0Q1dFI=; b=PvOXWJhUUTDW1vCYf0LmBr7NaQVeUln9o2pK9gx0mdABpqejOJv6hNNmUOJbijri1f UfnTwuOdl8lzhdc7RuJpXZP704GqnGm+HglHSwW1XZFIxnphG5Bxl1rtk+fppPCVPUwx Ul+DNS6KizIic0zBGg0/dILaoOnEdY31dSBqntqP2/0IfuiWMvXmE6dTCzJ7mN921UgM dsPbO4FJ74jrVrva9cEXGKCkTnyAcYMfmlSGnQWJZ+K7U3Ny76TDqwxPO8Z8r6bNzfy9 YygSGLTc/nUK6IPatWKV/4u1F7SGskMSwEmXgE/PmOYuwbL1DNr6fGMCXQSYnDAMIssM hAog== X-Gm-Message-State: AOAM530Cy+TakX6PFpvcQ16x5pikRg8MPFDDeATSQ0kZ+BNagprnrm6/ YlKZJuqo2r6rFQky1nzD2kKG8tPWFEw= X-Google-Smtp-Source: ABdhPJwHzQxTUk2poQEvPefexHM2rCG6v4bWi8K0lIwdP1t85Z9qIRLULXuB0PDNsstcO9cNptlpew== X-Received: by 2002:a37:38f:: with SMTP id 137mr4500746qkd.498.1619191490347; Fri, 23 Apr 2021 08:24:50 -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 h7sm4352902qtj.15.2021.04.23.08.24.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Apr 2021 08:24:50 -0700 (PDT) Subject: Re: [PATCH] add attribute none to pthread_setspecific (BZ #27714) To: Paul Eggert Cc: GNU C Library References: <2ec7fadb-cc15-a005-f708-d2adecc8cc39@gmail.com> <6c23d4f8-9c48-6bf6-ed13-a02ac66bc92b@cs.ucla.edu> From: Martin Sebor Message-ID: Date: Fri, 23 Apr 2021 09:24:48 -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: <6c23d4f8-9c48-6bf6-ed13-a02ac66bc92b@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 23 Apr 2021 15:24:53 -0000 On 4/22/21 6:11 PM, Paul Eggert wrote: > On 4/22/21 2:30 PM, Martin Sebor via Libc-alpha wrote: > >> -    __THROW; >> +    __THROW __attr_access_none (2); > > Instead of inventing a new __attr_access_none macro that developers will > need to remember, why not add support to the existing __attr_access > macro? That is, uses can look like this: > >      __THROW __attr_access ((__none__, 2)); > > if we define __attr_access with something like the attached patch. I don't have a preference for how to define the macro. I went with a new one because Joseph suggested that approach in hist comments on the mismatched allocation patch (for the __attr_dealloc macros). The other approach I considered was using the __attr_access macro but guarding it for GCC 11 in situ. Since functions like pthread_setspecific are exceeingly rare, I don't expect the new attribute to be used very much at all (if you do know of other such functions, though, please let me know so I can annotate them as well). As for your suggested change. I think we considered variadic macros when we first introduced the attribute but rejected it for some reason that I'm not sure I remember. Maybe because they're a C99 feature and Glibc supports older compilers? If this isn't the case and others share your preference for this approach I don't mind changing it. > > Alternatively, one could keep both cdefs.h and the callers simple by > doing access attribute checking only for GCC 11 and later. That'd be > good enough in the long run. I'd view disabling the checking with older GCC releases as a QoI regression, so I'm not in favor of this alternative. Martin