Messages in this thread | | | Date | Sat, 24 Feb 2007 12:11:24 +0100 | From | Vojtech Pavlik <> | Subject | Re: [KJ][RFC][PATCH] BIT macro cleanup |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |