On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote: > This kind of memcpy() is error-prone. Its replacement with a struct > assignment is prefered because it's type-safe and much easier to read. > > Found by coccinelle. Hand patched and reviewed. > Tested by compilation only. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) > > // <smpl> > @@ > identifier struct_name; > struct struct_name to; > struct struct_name from; > expression E; > @@ > -memcpy(&(to), &(from), E); > +to = from; > // </smpl> > > Signed-off-by: Peter Senna Tschudin <peter.senna@xxxxxxxxx> > Signed-off-by: Ezequiel Garcia <elezegarcia@xxxxxxxxx> > --- > drivers/media/tuners/tuner-xc2028.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c > index 7bcb6b0..0945173 100644 > --- a/drivers/media/tuners/tuner-xc2028.c > +++ b/drivers/media/tuners/tuner-xc2028.c > @@ -870,7 +870,7 @@ check_device: > } > > read_not_reliable: > - memcpy(&priv->cur_fw, &new_fw, sizeof(priv->cur_fw)); > + priv->cur_fw = new_fw; This memcpy() can get called almost every time tuner-xc2028.c:generic_set_freq() is called. This copies a 32 byte (I think) structure on a 32 bit machine. I am assuming the difference in performance between the memcpy and assignment operator is negligible. Regards, Andy > /* > * By setting BASE in cur_fw.type only after successfully loading all -- 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
