linux-kernel - Re: [KJ][RFC][PATCH] BIT macro cleanup

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Feb 2007 23:43:44 +0100
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Milind Choudhary <milindchoudhary@...il.com>,
	kernel-janitors@...ts.osdl.org, linux-kernel@...r.kernel.org,
	linux-input@...ey.karlin.mff.cuni.cz,
	linux-joystick@...ey.karlin.mff.cuni.cz
Subject: Re: [KJ][RFC][PATCH] BIT macro cleanup

Dmitry Torokhov wrote:
> On 2/23/07, Richard Knutsson <ricknu-0@...dent.ltu.se> wrote:
>> Dmitry Torokhov wrote:
>> >
>> > Hm, I thought as was clear, but apparently I messed up explaining my
>> > position:
>> >
>> > 1. I don't like BITWRAP name at all and I don't want anything like
>> > that near input code. I think BIT is just fine.
>> Oh, I think I understand now. So the (in input.h):
>> #undef BIT
>> #define BIT(...
>> business is what you want to do? Well, that I will not object to.
>
> No, #undefs may be barely tolerable in .c files but they are not
> acceptable in core subsystem interfaces. If you do that you will never
> know what version of BIT patricular module is using.
Yes, kinda. But wouldn't the compiler complain if you included both 
input.h and bitops.h (multiply definitions of BIT)?
>>  Your
>> patch with:
>> +#define BIT(nr)        (1UL << (nr))
>> +#define LLBIT(nr) (1ULL << (nr))
>> +#define BITWRAP(nr)    (1UL << ((nr) % BITS_PER_LONG))
>> in bitops.h made me believe the #undef in input.h was just a temporarily
>> thing.
>
> No. There is no "my patch". You are confusing me with Milind
> Choudhary. 
Sorry about that. Am surprised I didn't notice it earlier...
> I am saying that IMO input's BIT definition should be
> adequate for 99% of potential users and that I would be OK with moving
> said BIT definition from input.h to bitops.h and maybe supplementing
> it with LLBIT. I am also saying that I do not want BITWRAP, BITSWAP
> (what swap btw?) nor BIT(x % BITS_PER_LONG) in input drivers.
Is the reason for the modulo to put a bitmask larger then the variable 
into an array? I did just a quick 'grep' for "BIT(" in drivers/input/ 
and from what I saw, most (or all?) of the values are defined constants 
and those in input.h were noway near the limits of a 'long'.
The reason I don't like it with modulo is simply because it hides 
potential bugs (when x is to big). And what about the "1%"?
IMHO BIT should be as simple as possible.

Richard Knutsson

-
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/