Re: [PATCH] rtl2832: remove compiler warning
From: Luis de Bethencourt
Date: Tue Feb 10 2015 - 09:07:41 EST
On Tue, Feb 10, 2015 at 12:57:24PM +0200, Antti Palosaari wrote:
> On 02/09/2015 12:44 AM, Luis de Bethencourt wrote:
> >Cleaning the following compiler warning:
> >rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function
> >Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
> >tmp, this line would never run because we go to err. It is still nice to avoid
> >compiler warnings.
> >Signed-off-by: Luis de Bethencourt <luis.bg@xxxxxxxxxxx>
> > drivers/media/dvb-frontends/rtl2832.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c
> >index 5d2d8f4..ad36d1c 100644
> >--- a/drivers/media/dvb-frontends/rtl2832.c
> >+++ b/drivers/media/dvb-frontends/rtl2832.c
> >@@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, fe_status_t *status)
> > struct rtl2832_dev *dev = fe->demodulator_priv;
> > struct i2c_client *client = dev->client;
> > int ret;
> >- u32 tmp;
> >+ u32 tmp = 0;
> > dev_dbg(&client->dev, "\n");
> I looked the code and I cannot see how it could used as uninitialized. Dunno
> how it could be fixed properly.
I agree. If rtl2832_rd_demod_reg() in line 696 doesn't set tmp it is because
it has errored out. Which means rtl2832_read_status() itself will goto err
before the check for 'if (tmp == 11)' line that generates the warning.
I mentioned this in my commit message :)
> Also, I think idiom to say compiler that variable could be uninitialized is
> to store its own value. But I am fine with zero initialization too.
> u32 tmp = tmp;
If you prefer I use the 'u32 tmp = tmp;' I am happy to change my patch.
You say you are fine with zero initialization too, but I prefer offering
whatever you think is best.
Thanks for taking the time to look at this,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/