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=-2.9 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 45DBE1F5AE for ; Fri, 23 Apr 2021 15:24:55 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1D0073944815; Fri, 23 Apr 2021 15:24:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D0073944815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619191494; bh=6s+DOR3jWt8/lTY79T/0SnEUtepeq4l9ArH8H0Q1dFI=; 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=Bb/bqEPZHb8NoHCftAHFVudWAmbAO6jOZ6dq7Kf2YIRpwompFNfhaHGNtAfg5anTU w5nw05i7inHEvR9wfL/Q42+nsRoFsDp0b/R3LFcNb0C9Oca66EeL1HVZqXq/EGKdMo UPExEZB3E8YCovWuHSl8QcyA9j/S27HjCSPxJsFU= 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 References: <2ec7fadb-cc15-a005-f708-d2adecc8cc39@gmail.com> <6c23d4f8-9c48-6bf6-ed13-a02ac66bc92b@cs.ucla.edu> 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-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/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