On Wed, Jan 07, 2015 at 08:46:52PM -0800, John de la Garza wrote:
> On Sun, Jan 04, 2015 at 04:50:58PM -0800, Greg KH wrote:
> > On Sun, Jan 04, 2015 at 06:43:22PM -0500, John de la Garza wrote:
> > > I assume it is a bad idea to depend on true being 1, right? I mean, I
> > > should assume that tr
On Sun, Jan 04, 2015 at 08:17:15PM -0500, valdis.kletni...@vt.edu wrote:
> On Sun, 04 Jan 2015 18:43:22 -0500, John de la Garza said:
> > On Sat, Jan 03, 2015 at 11:20:29PM -0500, valdis.kletni...@vt.edu wrote:
> > > On Sat, 03 Jan 2015 18:54:00 -0500, John de la Garza said:
> > >
> > > > It should
On Sun, Jan 04, 2015 at 04:50:58PM -0800, Greg KH wrote:
> On Sun, Jan 04, 2015 at 06:43:22PM -0500, John de la Garza wrote:
> > I assume it is a bad idea to depend on true being 1, right? I mean, I
> > should assume that true could be changed to any non 0 value in the
future,
> > right?
>
> Why w
On Sun, 04 Jan 2015 18:43:22 -0500, John de la Garza said:
> On Sat, Jan 03, 2015 at 11:20:29PM -0500, valdis.kletni...@vt.edu wrote:
> > On Sat, 03 Jan 2015 18:54:00 -0500, John de la Garza said:
> >
> > > It should not be assumed that true will always be 1 as defined in
> > > include/linux/stddef
On Sun, Jan 04, 2015 at 06:43:22PM -0500, John de la Garza wrote:
> On Sat, Jan 03, 2015 at 11:20:29PM -0500, valdis.kletni...@vt.edu wrote:
> > On Sat, 03 Jan 2015 18:54:00 -0500, John de la Garza said:
> >
> > > It should not be assumed that true will always be 1 as defined in
> > > include/linu
On Sat, Jan 03, 2015 at 11:20:29PM -0500, valdis.kletni...@vt.edu wrote:
> On Sat, 03 Jan 2015 18:54:00 -0500, John de la Garza said:
>
> > It should not be assumed that true will always be 1 as defined in
> > include/linux/stddef.h, right?
>
> No, I mean use an actual 'bool' type rather than 'in
On Sat, 03 Jan 2015 18:54:00 -0500, John de la Garza said:
> It should not be assumed that true will always be 1 as defined in
> include/linux/stddef.h, right?
No, I mean use an actual 'bool' type rather than 'int'. Consider this from
kernel/softirq.c:
static inline bool lockdep_softirq_start(v
On Mon, Dec 29, 2014 at 08:00:08PM -0500, valdis.kletni...@vt.edu wrote:
> If you're *really* ambitious, converting stuff to use a boolean
> rather than an int where appropriate would be nice - we don't do that enough
> currently. But that will require actually reading and understanding the code.
On Mon, Dec 29, 2014 at 11:00 PM, wrote:
> On Mon, 29 Dec 2014 22:25:41 -0200, Vinícius Tinti said:
>
>> I was looking the kernel source code and there are a lot of places in
>> which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear.
>> As fair as I can tell both can be replaced by
On Mon, 29 Dec 2014 22:25:41 -0200, Vinícius Tinti said:
> I was looking the kernel source code and there are a lot of places in
> which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear.
> As fair as I can tell both can be replaced by "!!expression" and
> "!expression".
As far as th
On Mon, Dec 29, 2014 at 10:34 PM, Max Filippov wrote:
> On Tue, Dec 30, 2014 at 3:25 AM, Vinícius Tinti
> wrote:
>> I was looking the kernel source code and there are a lot of places in
>> which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear.
>> As fair as I can tell both can be
On Tue, Dec 30, 2014 at 3:25 AM, Vinícius Tinti wrote:
> I was looking the kernel source code and there are a lot of places in
> which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear.
> As fair as I can tell both can be replaced by "!!expression" and
> "!expression".
>
> Moreover th
Hi,
I was looking the kernel source code and there are a lot of places in
which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear.
As fair as I can tell both can be replaced by "!!expression" and
"!expression".
Moreover there it seems that using "!!" does not add a "nopl"
instruction
13 matches
Mail list logo
