On 2/23/07, Richard Knutsson [off-list ref] wrote:

Dmitry Torokhov wrote:

quoted

On 2/23/07, Richard Knutsson [off-list ref] wrote:

quoted

Milind Choudhary wrote:

quoted

On 2/23/07, Richard Knutsson [off-list ref] wrote:

quoted

quoted

+#define BITWRAP(nr)    (1UL << ((nr) % BITS_PER_LONG))

& make the whole input subsystem use it
The change is huge, more than 125 files using input.h
& almost all use the BIT macro.

It is as a big of change, but have you dismissed the "BIT(nr %
BITS_PER_LONG)" approach?

no..
but just looking at the number of places it is being used,
it seems that adding a new  macro would be good
which makes it look short n sweet

You have a point there but I still don't think it should be in bitops.h.
Why should we favor long-wrap before byte-wrap, so what do you think
about doing:

#define BITWRAP(x)      BIT((x) % BITS_PER_LONG)

in input.h? Otherwise I think it should be call LBITWRAP (or something)
to both show what kind it is and enable us to add others later.

Why would you not want to have what you call bitwrap as a standard
behavior? Most placed to not use modulus because they know the kind of
data they are working with but should still be fine if generic
implementation did that.

Both because I find the name not as expressive as simple "BIT(x %
something)",

I was not talking about name (I hate BITWRAP) but behavior.

but mainly since it only enables wrapping of the long-type.

I'd provde BIT and separate LLBIT for ones who really need long long.
People who intereseted in smaller than BITS_PER_LONG bitmaps shoud use
your proposal - BIT(x % DESIRED_WITH) and BIT should do modulo
BITS_PER_LONG internally.

-- 
Dmitry