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
>
prev parent 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).