[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR12MB582533E5A1A8D2E9E2C1691499D89@BL1PR12MB5825.namprd12.prod.outlook.com>
Date: Fri, 27 May 2022 14:13:09 +0000
From: "Dawar, Gautam" <gautam.dawar@....com>
To: Dan Carpenter <dan.carpenter@...cle.com>,
Eugenio Perez Martin <eperezma@...hat.com>
CC: Stefano Garzarella <sgarzare@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
Jason Wang <jasowang@...hat.com>,
Zhu Lingshan <lingshan.zhu@...el.com>,
"martinh@...inx.com" <martinh@...inx.com>,
"ecree.xilinx@...il.com" <ecree.xilinx@...il.com>,
Eli Cohen <elic@...dia.com>, Parav Pandit <parav@...dia.com>,
Wu Zongyong <wuzongyong@...ux.alibaba.com>,
"dinang@...inx.com" <dinang@...inx.com>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Xie Yongji <xieyongji@...edance.com>,
"lulu@...hat.com" <lulu@...hat.com>,
"martinpo@...inx.com" <martinpo@...inx.com>,
"pabloc@...inx.com" <pabloc@...inx.com>,
Longpeng <longpeng2@...wei.com>,
"Piotr.Uminski@...el.com" <Piotr.Uminski@...el.com>,
"Kamde, Tanuj" <tanuj.kamde@....com>,
Si-Wei Liu <si-wei.liu@...cle.com>,
"habetsm.xilinx@...il.com" <habetsm.xilinx@...il.com>,
"lvivier@...hat.com" <lvivier@...hat.com>,
Zhang Min <zhang.min9@....com.cn>,
"hanand@...inx.com" <hanand@...inx.com>
Subject: RE: [PATCH v3 2/4] vhost-vdpa: introduce STOP backend feature bit
[AMD Official Use Only - General]
IMHO replacing "return ops->stop;" with "return ops->stop?true:false;" should be good enough.
On Fri, May 27, 2022 at 08:50:16AM +0200, Eugenio Perez Martin wrote:
> On Thu, May 26, 2022 at 9:07 PM Dan Carpenter <dan.carpenter@...cle.com> wrote:
> >
> > On Thu, May 26, 2022 at 07:00:06PM +0200, Eugenio Perez Martin wrote:
> > > > It feels like returning any literal that isn't 1 or 0 should
> > > > trigger a warning... I've written that and will check it out tonight.
> > > >
> > >
> > > I'm not sure this should be so strict, or "literal" does not include pointers?
> > >
> >
> > What I mean in exact terms, is that if you're returning a known
> > value and the function returns bool then the known value should be 0 or 1.
> > Don't "return 3;". This new warning will complain if you return a
> > known pointer as in "return &a;". It won't complain if you return
> > an unknown pointer "return p;".
> >
>
> Ok, thanks for the clarification.
>
> > > As an experiment, can Smatch be used to count how many times a
> > > returned pointer is converted to int / bool before returning vs
> > > not converted?
> >
> > I'm not super excited to write that code... :/
> >
>
> Sure, I understand. I meant if it was possible or if that is too far
> beyond its scope.
To be honest, I misread what you were asking. GCC won't let you return a pointer with an implied cast to int. It has to be explicit. So there are zero of those. It's not hard to look for pointers with an implied cast to bool.
static void match_pointer(struct expression *ret_value) {
struct symbol *type;
char *name;
type = cur_func_return_type();
if (!type || sval_type_max(type).value != 1)
return;
if (!is_pointer(ret_value))
return;
name = expr_to_str(ret_value);
sm_msg("'%s' return pointer cast to bool", name);
free_string(name);
}
regards,
dan carpenter
Powered by blists - more mailing lists