| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAD6G_RRwnCpMsRQg97rebuQq3PxoKxFKj9vfZsXH+J62TBE-WQ@mail.gmail.com> Date: Thu, 21 May 2015 01:20:47 +0530 From: Jagan Teki <jteki@...nedev.com> To: Jens Axboe <axboe@...nel.dk> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Wolfram Sang <wsa@...-dreams.de> Subject: Re: [PATCH] block: Use BIT macro from include/linux/bitops.h On 21 May 2015 at 01:13, Jens Axboe <axboe@...nel.dk> wrote: > On 05/20/2015 01:41 PM, Jagan Teki wrote: >> >> On 21 May 2015 at 00:52, Jens Axboe <axboe@...nel.dk> wrote: >>> >>> On 05/18/2015 01:14 PM, Jagan Teki wrote: >>>> >>>> >>>> Replace (1 << nr) to BIT(nr) where nr = 0, 1, 2 .... 31 >>> >>> >>> >>> I don't like it, I think it hurts readability. >> >> >> What do you mean by don't like, using kernel defined macro instead of >> numerical assignments huts readability? > > > In the context of the patch, BIT(0) == (1 << 0) is obvious. But if I just > came across BIT(7) in the code, I'd have to check, whereas anyone would > immediately know that (1 << 7) is the 7th bit set. Hence, readability is > worse, and that's important. I don't how that BIT(7) is tricky to understand as BIT(0) implies to be set 0th bit. If understanding of BIT(0) is same like to be as BIT(7) and these were simplified macro's used most of the code in kernel. -- Jagan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists