lkml.org 
[lkml]   [2016]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 07/17] usb: host: ehci-dbg: fix unsigned comparison
From
2016-01-04 17:50 GMT-03:00 Alan Stern <stern@rowland.harvard.edu>:
> On Mon, 4 Jan 2016, Geyslan G. Bem wrote:
>
>> This patch fixes an unsigned comparison to less than 0.
>
> No, it doesn't. It changes an unsigned comparison for less than or
> equal to 0, which is very different from less than 0.
You're right. The statemant is incomplete.

>
>> Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
>> ---
>>
>> Notes:
>> I'm not sure about that comparison because in qh_lines() temp receives
>> the snprintf() return and thereafter occurs this comparison:
>>
>> if (size < temp)
>> temp = size;
>>
>> Is it a test of string truncation right? That possibility is being
>> treated. But if after some snprintf returns the temp is exactly size
>> minus 1 (trailing null)? Could this scenario happen? If yes, I think
>> size could be not counting correctly. Let me know more about it.
>
> I think the two weird code sequences in qh_lines() were written before
> scnprintf existed. They should be changed to use scnprintf instead of
> snprintf; then the "if (size < temp) temp = size;" things can be
> removed.
I see. I can do another patch for that if you allow me.

>
>> drivers/usb/host/ehci-dbg.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
>> index 980ca55..1645120 100644
>> --- a/drivers/usb/host/ehci-dbg.c
>> +++ b/drivers/usb/host/ehci-dbg.c
>> @@ -542,7 +542,7 @@ static ssize_t fill_async_buffer(struct debug_buffer *buf)
>> next += temp;
>>
>> list_for_each_entry(qh, &ehci->async_unlink, unlink_node) {
>> - if (size <= 0)
>> + if (size == 0)
>> break;
>> qh_lines(ehci, qh, &next, &size);
>> }
>
> The new line does exactly the same thing as the old line. There's no
> reason to make this change.
I think that the original and new logic will be the same because the
size variable has no sign. If in some previous subtraction the
subtracted value is greater than size value, this will spin (rotate),
probably, to a great positive value.

The compiled code will not change indeed. That change was only focused
on the improvement of the code reading. So if you allow me I could
change the commit message. If not let's forget it. :-)

>
> Alan Stern
>



--
Regards,

Geyslan G. Bem
hackingbits.com


\
 
 \ /
  Last update: 2016-01-04 23:01    [W:0.062 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site