From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 685943857809; Wed, 23 Mar 2022 16:31:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 685943857809 Received: by mail-il1-x12e.google.com with SMTP id j15so1352516ila.13; Wed, 23 Mar 2022 09:31:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AhLgeCM4WjBhd/9lzQZtXCbCuKqNlkQyvDLS3BaSu5E=; b=Dl+2pBFluMCvi/1lwCgK85ATaVqruxAWTM020wSyIi1VVMCCahvpk1J1fLWSTo20SH 1lo0acVTQJFvF5phVzpXtZc7nUR8DWWW5PKYztMxO2b1iMymqeAluu7lXns50YK5M0L3 +lPZDWrgHbIY8pC3n0n4x33dWoBpI/VFNi9exuaXwwxr6qtBa992skfjfy4dSbkdhqfh jloJyorLO7e4nwtG0ao73dfc8ffU6tGQOoFC603GX84PvxmS45+I17pr3MJOrGppC2Fi fAc0zD5Nzv94gEX1k2H+HPK9A5aYtIZVAask2dKwrDEjTZsUksUgDi/O0sTvmiHd9Mw4 pSGw== X-Gm-Message-State: AOAM533t2X8aZ6gCyBTsJ5xEtDwRpT6t0klyLXjEzjYbP2KxgvJk89Gv 5utJeZ8sTTr/zP4yEvxnbHmHGghwZy4= X-Google-Smtp-Source: ABdhPJxX7Kn4e6GcxAWmklyK3vnb3EVc9NSv2+Ov78/bK3N2WZs1PlxA0rBXRDqvaTBYPbRygfBP5g== X-Received: by 2002:a05:6e02:1a01:b0:2c7:a5cb:a189 with SMTP id s1-20020a056e021a0100b002c7a5cba189mr441081ild.247.1648053115318; Wed, 23 Mar 2022 09:31:55 -0700 (PDT) Received: from [192.168.0.41] (174-16-121-59.hlrn.qwest.net. [174.16.121.59]) by smtp.gmail.com with ESMTPSA id l14-20020a05660227ce00b00645ebb013c1sm216367ios.45.2022.03.23.09.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 09:31:55 -0700 (PDT) Message-ID: <16768247-eacc-100c-fded-9aa42833867f@gmail.com> Date: Wed, 23 Mar 2022 10:31:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2] Document that the 'access' and 'nonnull' attributes are independent Content-Language: en-US To: David Malcolm , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org References: <20220323130117.525495-1-dmalcolm@redhat.com> From: Martin Sebor In-Reply-To: <20220323130117.525495-1-dmalcolm@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, 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, 23 Mar 2022 16:31:58 -0000 On 3/23/22 07:01, David Malcolm wrote: > On Mon, 2022-03-14 at 16:18 -0600, Martin Sebor wrote: >> On 3/9/22 14:57, David Malcolm via Gcc wrote: >>> On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote: >>>> 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 for the clarification... >>> >>>> >>>> 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, ...)) >>> >>> ...so that's (a) then. >>> >>> I think it might be more user-friendly to be explicit about this in >>> the >>> documentation, maybe something like the attached? >> >> I agree it's worth clarifying the manual. >> >> But I don't think there's a way to annotate a function to indicate >> that it will definitely access an object (or dereference a pointer). >> Attribute access just implies that it might dereference it (unless >> the size is zero), and attribute nonnull that the pointer must not >> be null, not that it will be dereferenced (or even that it must be >> valid, although that's implied by the language and should probably >> be enforced in all contexts by some other warning). >> >> The combination of access with nonzero size and nonnull only means >> that the pointer must be nonnull and point to an object with at least >> size elements. > > Here's an updated version of the patch which expresses that also. > > OK for trunk? > > Dave > >> >> Martin >> >>> >>> (not yet fully tested, but seems to build) >>> >>> Dave >>> >>> >>> >>> >>>>> >>>>> (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 >>>>> >>>> >>> >> > > gcc/ChangeLog: > * doc/extend.texi (Common Function Attributes): Document that > 'access' does not imply 'nonnull'. > > Signed-off-by: David Malcolm > --- > gcc/doc/extend.texi | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index a4a25e86928..790014f3da5 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -2652,6 +2652,15 @@ The mode is intended to be used as a means to help validate the expected > object size, for example in functions that call @code{__builtin_object_size}. > @xref{Object Size Checking}. > > +Note that the @code{access} attribute merely specifies how an object > +referenced by the pointer argument can be accessed; it does not imply that > +an access @strong{will} happen. If the pointer will definitely be > +dereferenced, you may want to also add > +@code{__attribute__((nonnull (@var{arg-index})))} to the function for the > +pointer parameter in question (though the presence of the @code{nonnull} > +attribute does not imply that the parameter will be dereferenced, merely > +that it must be non-null). > + > @item alias ("@var{target}") > @cindex @code{alias} function attribute > The @code{alias} attribute causes the declaration to be emitted as an alias I'm sorry, I probably wasn't clear. This text sounds contradictory: If the pointer will definitely be dereferenced ... does not imply that the parameter will be dereferenced... The concern is that the constraints implied by atttributes access and nonnull are independent of each other. I would suggest to document that without talking about dereferencing because that's not implied by either of them. E.g., something like this (feel free to tweak it as you see fit): Note that the @code{access} attribute doesn't imply the same constraint as attribute @code{nonnull} (@pxref{Attribute nonnull}). The latter attribute should be used to annotate arguments that must never be null, regardless of the value of the size argument. A couple of tests that show the difference are gcc.dg/Wstringop-overflow-{23,24}.c. GCC issues -Wnonnull for just a subset of calls to functions with attribute access with a null pointer (those with a nonzero size argument). Adding attribute nonnull would make it issue -Wnonnull in all of them. Martin