From: Steven Rostedt <rostedt@goodmis.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] tracing: silence GCC 9 array bounds warning
Date: Wed, 22 May 2019 09:34:53 -0400 [thread overview]
Message-ID: <20190522093453.25e601a5@gandalf.local.home> (raw)
In-Reply-To: <CANiq72=uRuyDuRvZgxYAHxKRCOyJ-KQew+R24tPwOJuQmaO1Yw@mail.gmail.com>
On Wed, 22 May 2019 15:11:10 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Wed, May 22, 2019 at 1:52 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Wed, 22 May 2019 11:58:10 +0200
> > Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > > +/* reset all but tr, trace, and overruns */
> > > +static __always_inline void trace_iterator_reset(struct trace_iterator *iter)
> > > +{
> > > + /*
> > > + * We do not simplify the start address to &iter->seq in order to let
> > > + * GCC 9 know that we really want to overwrite more members than
> > > + * just iter->seq (-Warray-bounds).
> >
> > This comment is fine for the change log, but here it is too specific.
> > Why does one care about GCC 9 when we are at version GCC 21? I care
> > more about why we are clearing the data and less about the way we are
> > doing it.
>
> Since the code is not written the obvious way on purpose, the idea is
> to document why that is so -- otherwise the reader may wonder (and
> possibly re-introduce it back). Specifying when the warning started
> appearing tends to be clarifying, too.
>
> The commit message explains the change itself, but the comment
> explains why the current code is written like that.
Could also be shorten to: "Keep gcc from complaining about overwriting
more than just one member in the structure."
>
> > A comment like:
> >
> > /*
> > * Reset the state of the trace_iterator so that it can read
> > * consumed data. Normally, the trace_iterator is used for
> > * reading the data when it is not consumed, and must retain
> > * state.
> > */
> >
> > That is more useful than why we have the offset hack.
>
> That comment would be great in the function's description, in my
> opinion, and it is a great addition to have nevertheless. I re-used
> the existing comment for that to keep the change as minimal as
> possible (and nevertheless I am not qualified to write it since I have
> not studied the tracing code). In other words, I'm not saying there
> are no further improvements :-)
I put it there so you have an idea what the rational was ;-)
-- Steve
prev parent reply other threads:[~2019-05-22 13:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 9:58 [PATCH v2] tracing: silence GCC 9 array bounds warning Miguel Ojeda
2019-05-22 11:52 ` Steven Rostedt
2019-05-22 13:11 ` Miguel Ojeda
2019-05-22 13:34 ` Steven Rostedt [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=20190522093453.25e601a5@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@redhat.com \
--cc=torvalds@linux-foundation.org \
/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 NNTP newsgroup(s).