Re: [KJ][RFC][PATCH] BIT macro cleanup

[Vojtech Pavlik <vojtech@suse.cz>]

On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:

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

And I totally agree with Dmitry. The "% BITS_PER_LONG" doesn't hurt
other users, and it's needed for larger-than-single-long bit arrays.

> Is the reason for the modulo to put a bitmask larger then the variable 
> into an array?

The complementary LONG() macro will tell you the index of an array of
longs where the bit should be set.

> 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'.

Well, many do not need it, but for example BIT(BTN_LEFT) does, and
that's used in a lot of places.

> The reason I don't like it with modulo is simply because it hides 
> potential bugs (when x is to big). 

That would be my only concern - losing compiler warnings.

> And what about the "1%"?

The 1% will need either LLBIT or an extra % 8.

> IMHO BIT should be as simple as possible.

-- 
Vojtech Pavlik
Director SuSE Labs