From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) by sourceware.org (Postfix) with ESMTPS id EE96D3858C74 for ; Wed, 9 Mar 2022 21:31:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE96D3858C74 Received: by mail-vs1-xe36.google.com with SMTP id h30so3823835vsq.13 for ; Wed, 09 Mar 2022 13:31:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rvrvn66tUOTru0hR0lbDO2tsE3NEqwiOl59DVzaMb6s=; b=PkFAZfr3srjLKk/7KZfoczGiDYLphHOn6AKpkDB94cf6bJ01hMTiTkR5ESpH07hWg+ SlqHvm/RUFAHyYyNPDn9iPbUJpo+hXJM96Ds31kHRLGUp52kBOQKESaZGib0K9MWHJwO 4tNrJ/xfzZ+49k9qXWBJS2A1oiuE00TbK09IELzVITqoM66i2Sm5gg2xHVrN6P61o5hT zfxhdVEMeXJfLp6sB2ByICH004Mew4PQdn+3kxdQiohLLbmDPavJVeJTG/rtWY61nrSJ bqT0AFoi3Rk8eJ4lDR/gMbDK4d3BOyRudbtxPZ4HhOEt86Adv404efq5TdAwKkY2GPy1 /18g== X-Gm-Message-State: AOAM533O0JceZBiA9FoeJUOpsHbHSmAFgTaAb7Q1T1G3BVxIMIH0QCbe IqWcyxQNYjXsM7lYEAXMKPa419q63JX9N6bYYvvvBwEi X-Google-Smtp-Source: ABdhPJwVe54DWeVAk1ty3H3sC5l5duugOupI4+OcOdihj6kQ6Ffo9kHDu6fQVXNjjFoPFzHssVCvrXc37N8BcF6xGxk= X-Received: by 2002:a67:be15:0:b0:322:8c36:62b8 with SMTP id x21-20020a67be15000000b003228c3662b8mr882835vsq.69.1646861462244; Wed, 09 Mar 2022 13:31:02 -0800 (PST) MIME-Version: 1.0 References: <2b899f7a1c9d9e57e1bb165405d8e57b1c86b889.camel@redhat.com> In-Reply-To: <2b899f7a1c9d9e57e1bb165405d8e57b1c86b889.camel@redhat.com> From: Andrew Pinski Date: Wed, 9 Mar 2022 13:30:48 -0800 Message-ID: Subject: Re: __attribute__ ((access, ...)) vs __attribute__ ((nonnull)) To: David Malcolm Cc: GCC Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 21:31:05 -0000 On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc wrote: > > We gained __attribute__ ((access, ...)) in GCC 10: > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html > which identifies one of the pointer/reference arguments of a function > as being accessed according to an access-mode: read_only, read_write, > write_only, or none. > > We also have __attribute__ ((nonnull)) to indicate that a function > argument (or all of them) must be non-NULL. > > There doesn't seem to be a relationship between these in the > implementation, but it strikes me that almost anywhere that a user > might use the "access" attribute, that parameter is probably going to > be required to be nonnull - though perhaps there are cases where APIs > check for NULL and reject them gracefully? No, I think they are separate. The access just says these access attributes are read only, write only, read-write or don't access what the pointer points to; it does not say they have to be read or written to. I think it is a bad idea to connect the two ideas because you could have some cases where an argument is optional but is only read from; or is only written to (there are many in GCC sources even). Thanks, Andrew Pinski > > Might we want to somehow make __attribute__ ((access, ...)) imply > __attribute__ ((nonnull))? (for non "none" access modes, perhaps?) > > If so, one place to implement this might be in tree.cc's > get_nonnull_args, and have it add to the bitmap any arguments that > have an appropriate access attribute. > > get_nonnull_args is used in various places: > - validating builtins > - in ranger_cache::block_apply_nonnull > - by -Wnonnull (in pass_post_ipa_warn::execute) > - by -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument; > I'm tracking the failure of these last two to make use of __attribute__ > ((access)) in PR analyzer/104860. > > So do we: > > (a) leave it up to the user, requiring them to specify __attribute__ > ((nonnull)) in addition to __attribute__ ((access, ...)) > > (b) leave it up to the individual sites in GCC that currently make use > of get_nonnull_args to add logic for handling __attribute__ ((access, > ...)) > > (c) extend get_nonnull_args > > ? > > Thoughts? > Dave >