[PATCH 05/18] Fix 64bit arch issue in synaptics eventcomm.c

Takashi Iwai tiwai at suse.de
Mon Oct 11 01:39:56 PDT 2010


At Mon, 11 Oct 2010 10:24:44 +0200 (CEST),
Mark Kettenis wrote:
> 
> > Date: Mon, 11 Oct 2010 09:47:56 +0200
> > From: Takashi Iwai <tiwai at suse.de>
> > 
> > At Fri, 08 Oct 2010 23:09:26 +0200,
> > Henrik Rydberg wrote:
> > > 
> > > On 10/08/2010 10:51 PM, Mark Kettenis wrote:
> > > 
> > > >> Date: Fri, 08 Oct 2010 21:36:02 +0200
> > > >> From: Takashi Iwai <tiwai at suse.de>
> > > >>
> > > >> At Fri, 8 Oct 2010 20:48:10 +0200 (CEST),
> > > >> Mark Kettenis wrote:
> > > >>>
> > > >>>> From: Takashi Iwai <tiwai at suse.de>
> > > >>>> Date: Fri,  8 Oct 2010 19:22:29 +0200
> > > >>>
> > > >>> Sorry, but it isn't obvious to me what issue this fixes.
> > > >>
> > > >> In C, "1" is an integer, not an unsigned long.
> > > >> Thus (1 << 33) doesn't give you the 33th bit shift, but it's undefined.
> > > > 
> > > > But if you'd actually use 33 (or event 32) as an offset, things
> > > > wouldn't work on a 32-bit platform would they?
> > > 
> > > 
> > > I believe this is what the patch is supposed to fix.
> > 
> > Yep :)
> > 
> > 
> > > > Anyway,
> > > > 
> > > >> If any, this must be (1UL << 32). 
> > > > 
> > > > This is the idiom that is much more common.  I probably wouldn't have
> > > > questioned things if you'd written it like that.  I recommend you to
> > > > stick to this version.
> > > 
> > > 
> > > For a counter-example, see the definition of test_bit() in the Linux kernel.
> > > 
> > > >> Also, it'd be better if such a test macro returns 1 instead of a
> > > >> random non-zero value.  So does my patch.
> > > > 
> > > > In C this doesn't matter.
> > > 
> > > 
> > > It is still useful to know if a logic expression evaluates to (0, 1) or (0,
> > > nonzero).
> > 
> > It does matter if the returned type is bigger.
> > Try an example code below on 32bit and 64bit machines:
> > 
> > ================================================================
> > #include <stdio.h>
> > 
> > #define LONG_BITS (sizeof(long) * 8)
> > #define OFF(x)   ((x) % LONG_BITS)
> > #define LONG(x)  ((x) / LONG_BITS)
> > 
> > #define TEST_BIT1(bit, array) (array[LONG(bit)] & (1 << OFF(bit)))
> > #define TEST_BIT2(bit, array) (array[LONG(bit)] & (1UL << OFF(bit)))
> > #define TEST_BIT3(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
> > 
> > static unsigned long test[4];
> > 
> > int main()
> > {
> > 	const int bit = 33;
> > 	int result;
> > 
> > 	/* set the bit */
> > 	test[LONG(bit)] |= 1UL << OFF(bit);
> > 
> > 	result = TEST_BIT1(bit, test);
> > 	printf("TEST1 %d = %d\n", bit, result);
> > 
> > 	result = TEST_BIT2(bit, test);
> > 	printf("TEST2 %d = %d\n", bit, result);
> > 
> > 	result = TEST_BIT3(bit, test);
> > 	printf("TEST3 %d = %d\n", bit, result);
> > 
> > 	return 0;
> > }
> > ================================================================
> > 
> > On a 32bit machine, it results in:
> >   TEST1 33 = 2
> >   TEST2 33 = 2
> >   TEST3 33 = 1
> > 
> > while on a 64bit machine, it results in:
> >   TEST1 33 = 0
> >   TEST2 33 = 0
> >   TEST3 33 = 1
> > 
> > See TEST2 still failed although it uses 1UL.
> 
> This example is meaningless.  On every reasonable 32-bit architecture,
> long is a 32-bit integer.  So
> 
> > 	/* set the bit */
> > 	test[LONG(bit)] |= 1UL << OFF(bit);
> 
> when bit is 33 (or even 32), is completely undefined on a 32-bit
> machine.  Therefore, you should never call TEST_BIT() with a first
> argument of 32 or larger, even on a 64-bit architecture, since the
> code wouldn't work on a 32-bit machine.

Hm?  TEST_BIT() is used for an long *array*, with the unlimited size.
Otherwise the macro should have been more simplified :)
Ditto for the above code.  It stores the value in an array member.
That's why LONG() and OFF() macros are used there.

> One can even argue that for this reason the change you're suggesting
> is dangerous, since people writing code on a 64-bit machine might not
> notice that they're writing coding that won't run on a 32-bit machine.

I wrote the patch because the detection of MT_* bits don't work on 64
bit machines actually.  So the current code _is_ just broken.


Takashi


More information about the xorg-devel mailing list