Re: [PATCH v2] tracing: silence GCC 9 array bounds warning

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