***
Please update your git repository and send a patch against current
linux-next. Once the "kbuild test robot" complains, it is too late
to send v2 patch. The other patch has already been applied and we
need a new patch.
***
I'm afraid I don't understand what your test program is trying to
demonstrate. :/ I think you're saying that using an "int" is not
a problem in this case. I'm not saying it's a bug, I'm saying it
makes the code harder to review.
Anyway, here is how type promotion works in C. Imagine you have a
condition like:
if (a < b) {
Both "a" and "b" are cast to the same type before the comparison.
The type depends on which out of "a" and "b" can hold a larger
positive value.
signed char 127 (7 positive bits)
unsgined char 255 (8 positive bits)
int 2147483647 (31 positive bits)
unsigned int 4294967295 (32 positive bits)
etc...
If both sides have less than 31 positive bits then they are cast to
int. Otherwise, you take the larger type and cast to that.
So if you have:
if ((int)-2 > (unsigned int)5)
printf("a negative is a large positive.\n");
if ((int)2147483648 < (int)2)
printf("a large positive is now negative.\n");
The issue with using int in this patch is only that it makes the
code a little harder to review because I now have to look up the
type of probe_rsp->rawData[] to make sure it isn't changed to
negative. It's not a massive deal. Static checkers can figure this
out without any issue, it's just that when I'm reviewing code
manually this is how I think.
regards,
dan carpenter
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
