Milind Arun Choudhary wrote:
why bitops.h? coz BIT qualifies for a "bitop"
& bitops.h is inclued by kernel.h, hence accessible from every part
of the tree without mucb efforts
I don't think there is anyone who objects to this
c>but it is not sutaible for those who want to go beyond this
Milind Arun Choudhary wrote:
why bitops.h? coz BIT qualifies for a bitop
bitops.h is inclued by kernel.h, hence accessible from every part
of the tree without mucb efforts
I don't think there is anyone who objects to this
cbut it is not sutaible for those who want to go beyond this
On Saturday 24 February 2007 07:59, Richard Knutsson wrote:
> Vojtech Pavlik wrote:
> > On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
> >
> >
> >> Is the reason for the modulo to put a bitmask larger then the variable
> >> into an array?
> >>
> >
> > The complementary
On Saturday 24 February 2007 06:11, Vojtech Pavlik wrote:
> > 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.
>
I think most dangerous scenario is when both shift operands
On 12:11 Sat 24 Feb , Vojtech Pavlik wrote:
>
> That would be my only concern - losing compiler warnings.
yes
see
I wanted a single BIT macro which can be used by the whole tree
was looking for a multipurpose one. found it in input.h
so i thought i will put it at a common place
why
Vojtech Pavlik wrote:
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
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.
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
On Fri, Feb 23, 2007 at 01:44:41PM +0530, Milind Choudhary wrote:
> Hi all
> working towards the cleanup of BIT macro,
> I've added one to & cleaned some obvious users.
>
> include/linux/input.h also has a BIT macro
> which does a wrap
> so currently i've done something like
>
> +#undef
On Fri, Feb 23, 2007 at 01:44:41PM +0530, Milind Choudhary wrote:
Hi all
working towards the cleanup of BIT macro,
I've added one to linux/bitops.h cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
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
Vojtech Pavlik wrote:
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
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.
On 12:11 Sat 24 Feb , Vojtech Pavlik wrote:
That would be my only concern - losing compiler warnings.
yes
see
I wanted a single BIT macro which can be used by the whole tree
was looking for a multipurpose one. found it in input.h
so i thought i will put it at a common place
why bitops.h?
On Saturday 24 February 2007 06:11, Vojtech Pavlik wrote:
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.
I think most dangerous scenario is when both shift operands are not
On Saturday 24 February 2007 07:59, Richard Knutsson wrote:
Vojtech Pavlik wrote:
On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
Is the reason for the modulo to put a bitmask larger then the variable
into an array?
The complementary LONG() macro will
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> 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
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
>
>> but mainly since it only enables wrapping of the long-type.
>
> I'd provde BIT and separate LLBIT for ones who
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
>
>> 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.
>
Dmitry Torokhov wrote:
I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
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
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> Milind Choudhary wrote:
>> > On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> >> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >> >
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Milind Choudhary wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >
>> > & make the whole input subsystem use it
>> > The change is
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Milind Choudhary wrote:
> On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>> > +#define BITWRAP(nr)(1UL << ((nr) % BITS_PER_LONG))
>> >
>> > & make the whole input subsystem use it
>> > The change is huge, more than 125 files
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> +#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
On 2/23/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> +#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
Milind Choudhary wrote:
Hi all
working towards the cleanup of BIT macro,
I've added one to & cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL << ((nr) % BITS_PER_LONG))
Hi all
working towards the cleanup of BIT macro,
I've added one to & cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL << ((nr) % BITS_PER_LONG))
Is it advisible to
Hi all
working towards the cleanup of BIT macro,
I've added one to linux/bitops.h cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL ((nr) % BITS_PER_LONG))
Is it
Milind Choudhary wrote:
Hi all
working towards the cleanup of BIT macro,
I've added one to linux/bitops.h cleaned some obvious users.
include/linux/input.h also has a BIT macro
which does a wrap
so currently i've done something like
+#undef BIT
#define BIT(nr)(1UL ((nr) %
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
+#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
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
+#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
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
+#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
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
+#define BITWRAP(nr)(1UL ((nr) % BITS_PER_LONG))
make the whole input subsystem use it
The change is huge, more than 125
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Milind Choudhary wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
+#define BITWRAP(nr)(1UL ((nr) % BITS_PER_LONG))
make the whole
Dmitry Torokhov wrote:
I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
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
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
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
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
I was not talking about name (I hate BITWRAP) but behavior.
Oh, my bad :)
but mainly since it only enables wrapping of the long-type.
I'd provde BIT and separate LLBIT for ones who really
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] 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
Dmitry Torokhov wrote:
On 2/23/07, Richard Knutsson [EMAIL PROTECTED] 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
38 matches
Mail list logo