lkml.org 
[lkml]   [2019]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7]
Hi Finn,

On Tue, Mar 5, 2019 at 9:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> > On Tue, Mar 5, 2019 at 3:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > > Looks bogus to me.
> > > >
> > > > If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> > > > warning changes to,
> > > >
> > > > ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming offset [7, 8] is out of the bounds [0, 6] [-Warray-bounds]
> > > > __builtin_memcpy(dest, src, dest_len);
> > > >
> > > > The compiler has nothing to complain about here. dest is known to be
> > > > id->fr and dest_len is known to be sizeof(id->fr).
> > > >
> > > > The error message indicates that gcc has applied the bounds [0, 6] to dest
> > > > when in fact those are the bounds for src.
> > > >
> > >
> > > My mistake. GCC is right, it seems memcpy will read past the end of
> > > "5.0.0+".
> >
> > But only if the else branch is taken, which is not the case.
> >
>
> You and I know that, because we can see what values get passed to
> memcpy_and_pad(). But how is gcc to know that?

Gcc also sees (partly) what values get passed, else it would not give that
warning.

Still, should gcc give warnings based on branches that may or may not be
taken? I guess there are lots of cases in the kernel where this could lead
to false positives.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

\
 
 \ /
  Last update: 2019-03-05 10:04    [W:0.130 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site