As long as the variable doesn't get overflowed you would have a negation, you shouldn't do dri_data[5] = ptr->dri * 0xff; if ptr->dri it's 255, but if ptr->dri = 1 i.e. (like is set in zr36050_setup) then you would be getting the negation, -1. the Direct rendering support is a flag afaik, so in this case I believe is a worthy C obfuscated negation code :) btw, are you sure about this patch?I would contact the maintainer first, because and'ing that doesn't make much sense... Disclaimer, all this is: AFAIK! :)
On Tuesday 29 March 2005 09:58 pm, you wrote: > Måns Rullgård wrote: > > "Ronald S. Bultje" <[EMAIL PROTECTED]> writes: > >>--- linux-2.6.5/drivers/media/video/zr36050.c.old 16 Sep 2004 22:53:27 > >> -0000 1.2 +++ linux-2.6.5/drivers/media/video/zr36050.c 29 Mar 2005 > >> 20:30:23 -0000 @@ -419,7 +419,7 @@ > >> dri_data[2] = 0x00; > >> dri_data[3] = 0x04; > >> dri_data[4] = ptr->dri >> 8; > >>- dri_data[5] = ptr->dri * 0xff; > >>+ dri_data[5] = ptr->dri & 0xff; > > > > Hey, that's a nice obfuscation of a simple negation. > > It's not a negation. This statement always assigns zero to > dri_data[5] if dri_data is char[]. Looks like gcc isn't catching > this problem. > > > BTW, when assigning to a char type, is the masking really necessary at > > all? I can't see that it should make a difference. Am I missing > > something subtle? > > Well, it's a matter of readability mostly. For now at least, when > char is always 8 bytes... > > /mjt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
