Re: [KJ] BIT macro cleanup

[Jaco Kroon <jaco@kroon.co.za>]

[-- Attachment #1.1: Type: text/plain, Size: 1215 bytes --]

Milind Choudhary wrote:
> On 2/8/07, walter harms <wharms@bfs.de> wrote:
> 
>>
>>>There are different variants of BIT using (long|unsigned
>>>long|unsigned|unsigned char) etc.
>>>Do we need to create different macros for each type
>>>Or a single one which takes type as input?
>>
>>bit operations make only sense on integer, so why not stay with long
>>and cast it down if needed ? so you have only one function doing so.
> 
> 
> Michael Veeck  had submitted a patch for the same before
> http://lists.osdl.org/pipermail/kernel-janitors/2005-August/004737.html
> 
> there was some discussion on the list,which did not reach any
> conclusion I guess.
> so we have

> #define BIT(x) (1UL << (x) )
> #define BIT(x) (1UL << ((x) % BITS_PER_LONG))

These two are identical (on x86 hardware at least), except that
BITS_PER_LONG depends on the architecture, 32 on x86 and 64 on x86_64,
and the modulus applied by the CPU depends on the size of x ...

> #define BIT(x) (1ULL << (__builtin_constant_p(x) ? (x) : (x) % 64)

This won't compile (bracket mismatch), but I can't see why you'd want to
differentiate between x being a compiletime constant or a runtime
calculated value ... it just doesn't make sense for me.

Jaco

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3233 bytes --]

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors