Re: [PATCH] locktorture: Fix assignment of boolean variables
On Mon, 3 Dec 2018, Peter Zijlstra wrote: > On Mon, Dec 03, 2018 at 10:20:42AM +0100, Julia Lawall wrote: > > Personally, I would prefer that assignments involving boolean variables > > use true or false. It seems more readable. Potentially better for tools > > as well. > > Then those tools are broken per the C spec. > > > But if the community really prefers 0 and 1, then the test can > > be deleted. > > The C language spec, specifies _Bool as an integer type wide enough to > at least store 0 and 1. > > IOW, 0 and 1 are perfectly valid valus to assign to a _Bool. > > And fundamentally that has to be so. That's how computers work. 0 is > false, 1 is true. > > The kernel is not the place to try and abstract such stuff, C is our > portable assembler. We muck with hardware, we'd better know how the heck > it works. How about it it were suggested only in files that already use true and false somewhere? julia
Re: [PATCH] locktorture: Fix assignment of boolean variables
On Mon, Dec 03, 2018 at 10:20:42AM +0100, Julia Lawall wrote: > Personally, I would prefer that assignments involving boolean variables > use true or false. It seems more readable. Potentially better for tools > as well. Then those tools are broken per the C spec. > But if the community really prefers 0 and 1, then the test can > be deleted. The C language spec, specifies _Bool as an integer type wide enough to at least store 0 and 1. IOW, 0 and 1 are perfectly valid valus to assign to a _Bool. And fundamentally that has to be so. That's how computers work. 0 is false, 1 is true. The kernel is not the place to try and abstract such stuff, C is our portable assembler. We muck with hardware, we'd better know how the heck it works.
Re: [PATCH] locktorture: Fix assignment of boolean variables
On Mon, 3 Dec 2018, Peter Zijlstra wrote: > On Mon, Dec 03, 2018 at 09:35:00AM +0100, Peter Zijlstra wrote: > > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > > > Fix the following warnings reported by coccinelle: > > > > > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to > > > > 0/1 > > Not to mention that WARN is gramatically incorrect. We're not assigning > 'bool' to 0/1 but the other way around. > > What crap.. > > > So I strongly disagree with this. Anybody that has trouble with 0/1 vs > > false/true needs to stay the heck away from C. > > > > I would suggest we delete that stupid coccinelle scripts that generates > > these pointless warns. Personally, I would prefer that assignments involving boolean variables use true or false. It seems more readable. Potentially better for tools as well. But if the community really prefers 0 and 1, then the test can be deleted. julia
Re: [PATCH] locktorture: Fix assignment of boolean variables
* Peter Zijlstra wrote: > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > > Fix the following warnings reported by coccinelle: > > > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1 > > > kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1 > > > > > > This patch also makes the code more readable. > > > > > > Signed-off-by: Wen Yang > > > CC: Davidlohr Bueso > > > CC: "Paul E. McKenney" > > > CC: Josh Triplett > > > CC: linux-kernel@vger.kernel.org > > > > Adding the current maintainers on CC. > > So I strongly disagree with this. Anybody that has trouble with 0/1 vs > false/true needs to stay the heck away from C. Indeed, and it's actually *worse* to read, as 0/1 stands out more and is more compact than false/true... The only reasonable case where bool is recommended is when functions are returning it, to make sure there's no mishap returning something else. But for a plain .c variable? Nope. > I would suggest we delete that stupid coccinelle scripts that generates > these pointless warns. Ack. Thanks, Ingo
Re: [PATCH] locktorture: Fix assignment of boolean variables
On Mon, Dec 03, 2018 at 09:35:00AM +0100, Peter Zijlstra wrote: > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > > Fix the following warnings reported by coccinelle: > > > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 Not to mention that WARN is gramatically incorrect. We're not assigning 'bool' to 0/1 but the other way around. What crap.. > So I strongly disagree with this. Anybody that has trouble with 0/1 vs > false/true needs to stay the heck away from C. > > I would suggest we delete that stupid coccinelle scripts that generates > these pointless warns.
Re: [PATCH] locktorture: Fix assignment of boolean variables
On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > Fix the following warnings reported by coccinelle: > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1 > > kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1 > > > > This patch also makes the code more readable. > > > > Signed-off-by: Wen Yang > > CC: Davidlohr Bueso > > CC: "Paul E. McKenney" > > CC: Josh Triplett > > CC: linux-kernel@vger.kernel.org > > Adding the current maintainers on CC. So I strongly disagree with this. Anybody that has trouble with 0/1 vs false/true needs to stay the heck away from C. I would suggest we delete that stupid coccinelle scripts that generates these pointless warns.
Re: [PATCH] locktorture: Fix assignment of boolean variables
On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > Fix the following warnings reported by coccinelle: > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:682:2-19: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:688:2-19: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:648:2-20: WARNING: Assignment of bool to 0/1 > kernel/locking/locktorture.c:654:2-20: WARNING: Assignment of bool to 0/1 > > This patch also makes the code more readable. > > Signed-off-by: Wen Yang > CC: Davidlohr Bueso > CC: "Paul E. McKenney" > CC: Josh Triplett > CC: linux-kernel@vger.kernel.org Adding the current maintainers on CC. Thanx, Paul > --- > kernel/locking/locktorture.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c > index 7d0b0ed74404..cd95c01491d8 100644 > --- a/kernel/locking/locktorture.c > +++ b/kernel/locking/locktorture.c > @@ -645,13 +645,13 @@ static int lock_torture_writer(void *arg) > cxt.cur_ops->writelock(); > if (WARN_ON_ONCE(lock_is_write_held)) > lwsp->n_lock_fail++; > - lock_is_write_held = 1; > + lock_is_write_held = true; > if (WARN_ON_ONCE(lock_is_read_held)) > lwsp->n_lock_fail++; /* rare, but... */ > > lwsp->n_lock_acquired++; > cxt.cur_ops->write_delay(&rand); > - lock_is_write_held = 0; > + lock_is_write_held = false; > cxt.cur_ops->writeunlock(); > > stutter_wait("lock_torture_writer"); > @@ -679,13 +679,13 @@ static int lock_torture_reader(void *arg) > schedule_timeout_uninterruptible(1); > > cxt.cur_ops->readlock(); > - lock_is_read_held = 1; > + lock_is_read_held = true; > if (WARN_ON_ONCE(lock_is_write_held)) > lrsp->n_lock_fail++; /* rare, but... */ > > lrsp->n_lock_acquired++; > cxt.cur_ops->read_delay(&rand); > - lock_is_read_held = 0; > + lock_is_read_held = false; > cxt.cur_ops->readunlock(); > > stutter_wait("lock_torture_reader"); > @@ -700,7 +700,7 @@ static int lock_torture_reader(void *arg) > static void __torture_print_stats(char *page, > struct lock_stress_stats *statp, bool write) > { > - bool fail = 0; > + bool fail = false; > int i, n_stress; > long max = 0, min = statp ? statp[0].n_lock_acquired : 0; > long long sum = 0; > @@ -915,7 +915,7 @@ static int __init lock_torture_init(void) > > /* Initialize the statistics so that each run gets its own numbers. */ > if (nwriters_stress) { > - lock_is_write_held = 0; > + lock_is_write_held = false; > cxt.lwsa = kmalloc_array(cxt.nrealwriters_stress, >sizeof(*cxt.lwsa), >GFP_KERNEL); > @@ -946,7 +946,7 @@ static int __init lock_torture_init(void) > } > > if (nreaders_stress) { > - lock_is_read_held = 0; > + lock_is_read_held = false; > cxt.lrsa = kmalloc_array(cxt.nrealreaders_stress, >sizeof(*cxt.lrsa), >GFP_KERNEL); > -- > 2.19.1 >