Vicente Feito <[EMAIL PROTECTED]> writes: > 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. >> > 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...
It seems pretty obvious to me, that the code is supposed to store the high byte in dri_data[4], and the low byte in dri_data[5]. Mistyping & as * doesn't seem too unlikely, either. -- Måns Rullgård [EMAIL PROTECTED] - 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/
