public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Martin Sebor <msebor@gmail.com>,
	Sebastian Huber <sebastian.huber@embedded-brains.de>,
	gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: [PATCH v3] Document that the 'access' and 'nonnull' attributes are independent
Date: Tue, 05 Apr 2022 16:46:44 -0400	[thread overview]
Message-ID: <5518501264ed55fc4cb49061ea9716189e8477f8.camel@redhat.com> (raw)
In-Reply-To: <d23fff3a-785f-5faf-0375-9e1781547a74@gmail.com>

On Fri, 2022-03-25 at 14:38 -0600, Martin Sebor wrote:
> On 3/25/22 12:45, David Malcolm wrote:
> > On Wed, 2022-03-23 at 17:52 +0100, Sebastian Huber wrote:
> > > On 23/03/2022 17:31, Martin Sebor via Gcc-patches wrote:
> > > > 
> > > > 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.
> > > 
> > > I would not give an advice on using the nonnull attribute here.
> > > This
> > > attribute could have pretty dangerous effects in the function
> > > definition
> > > (removal of null pointer checks).
> > > 
> > 
> > That's a fair point.
> > 
> > Here's a v3 of the patch, which tones down the advice, and mentions
> > that
> > there are caveats when directing the reader to the "nonnull"
> > attribute.
> > 
> > How does this look?
> 
> This version looks good to me.

Thanks.

I tested this, and have gone ahead and pushed this to trunk
(as r12-8007-g0b5723d74f3a73).

Dave


> 
> Thanks
> Martin
> 
> > 
> > gcc/ChangeLog:
> >         * doc/extend.texi (Common Function Attributes): Document
> > that
> >         'access' does not imply 'nonnull'.
> > 
> > Signed-off-by: David Malcolm <dmalcolm@redhat.com>
> > ---
> >   gcc/doc/extend.texi | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index a4a25e86928..539dad7001d 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -2652,6 +2652,14 @@ 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.  Also, the @code{access} attribute
> > does not
> > +imply the attribute @code{nonnull}; it may be appropriate to add
> > both attributes
> > +at the declaration of a function that unconditionally manipulates
> > a buffer via
> > +a pointer argument.  See the @code{nonnull} attribute for more
> > information and
> > +caveats.
> > +
> >   @item alias ("@var{target}")
> >   @cindex @code{alias} function attribute
> >   The @code{alias} attribute causes the declaration to be emitted
> > as an alias
> 



      reply	other threads:[~2022-04-05 20:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 21:23 __attribute__ ((access, ...)) vs __attribute__ ((nonnull)) David Malcolm
2022-03-09 21:30 ` Andrew Pinski
2022-03-09 21:57   ` [PATCH] Document that the 'access' and 'nonnull' attributes are independent David Malcolm
2022-03-14 22:18     ` Martin Sebor
2022-03-23 13:01       ` [PATCH v2] " David Malcolm
2022-03-23 16:31         ` Martin Sebor
2022-03-23 16:52           ` Sebastian Huber
2022-03-25 18:45             ` [PATCH v3] " David Malcolm
2022-03-25 20:38               ` Martin Sebor
2022-04-05 20:46                 ` David Malcolm [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5518501264ed55fc4cb49061ea9716189e8477f8.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=msebor@gmail.com \
    --cc=sebastian.huber@embedded-brains.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).