On 05/15/2013 05:23 PM, Dan Carpenter wrote:
> ***
> 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");
In our case, it only casts one value type to the same type with the
other, before comparing.
> 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.
>
If the type of 'probe_rsp->rawData[]' is changed to 'char', it will
compare between 'char' and 'int', in this condition, casting to 'int' is
the normal way, all things are OK.
If use min_t(u8..., we have to look up the 'HCF_MAX_NAME_LEN' whether is
changed upper than 255.
And excuse me, my English is not quite well (neither reading nor
writing), so maybe misunderstand some of contents with each other.
Thanks.
--
Chen Gang
Asianux Corporation
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
