On Mon, 11 May 2015, Julia Lawall wrote:
>
>
> On Mon, 11 May 2015, Nicholas Mc Guire wrote:
>
> > On Sun, 10 May 2015, Dan Carpenter wrote:
> >
> > > I don't really have a strong opinion either way... It's unlikely that
> > > we will introduce a bug here and if we did, I think it would be caught
> > > immediately in testing.
> > >
> > > It's pretty common to treat the first member of a struct as special.
> > > What annoys me is when people do
> > >
> > > struct foo {
> > > int one, two, three;
> > > whatever;
> > > };
> > >
> > > memcpy(&foo.one, src, sizoef(struct foo));
> > >
> > > Argh!? These triger buffer overflows warnings in Smatch and I don't
> > > see the point since &foo.one is less readable than &foo! Oh well, I
> > > think these were common enough, I had to treat it as idiomatic and add a
> > > special case for them.
> > >
> > just ran a naive scanner for that pattern but only could find this one instance
> >
> > ./net/sctp/sm_make_chunk.c:3103 ugly memset
> > 3102 if (af->is_any(&addr))
> > 3103 memcpy(&addr.v4, sctp_source(asconf), sizeof(addr));
> >
> > my scanner ist:
> >
> > @uses_first@
> > identifier f;
> > idexpression s;
>
> Maybe generalize s (ie expression) and the size (ie, don't specify
> anything)? The sizeof could be a type also.
>
yup - adding the type check case finds two additional cases
but generalizing s to an expression did not change results
@uses_first@
identifier f;
type T;
idexpression T s;
identifier e;
position p;
@@
f(...){
<+...
(
* memcpy@p(&s.e,...,sizeof(s));
|
* memcpy@p(&s.e,...,sizeof(T));
)
...+>
}
./drivers/infiniband/hw/ehca/ehca_mcast.c:80 ugly memset
./drivers/infiniband/hw/ehca/ehca_mcast.c:117 ugly memset
./net/sctp/sm_make_chunk.c:3103 ugly memset
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
