Re: [PATCH 1/5] USB: gadget: Fix unused variable warning in ci13xxx_udc

[David Brown <davidb-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]

On Thu, Apr 28 2011, Pavan Kondeti wrote:

> On 4/28/2011 3:31 PM, Michal Nazarewicz wrote:
>> On Thu, 28 Apr 2011 09:58:17 +0200, Pavankumar Kondeti  
>> <pkondeti-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> 
>>> Signed-off-by: Pavankumar Kondeti <pkondeti-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> ---
>>>  drivers/usb/gadget/ci13xxx_udc.c |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/ci13xxx_udc.c  
>>> b/drivers/usb/gadget/ci13xxx_udc.c
>>> index e09178b..6a9ad59 100644
>>> --- a/drivers/usb/gadget/ci13xxx_udc.c
>>> +++ b/drivers/usb/gadget/ci13xxx_udc.c
>>> @@ -1843,7 +1843,7 @@ __releases(mEp->lock)
>>>  __acquires(mEp->lock)
>>>  {
>>>  	struct ci13xxx_req *mReq, *mReqTemp;
>>> -	int retval;
>>> +	int uninitialized_var(retval);
>>> 	trace("%p", mEp);
>> 
>> Could we instead set it to 0?
>>
>
> would it matter anyway? we return -EINVAL if the queue is empty.
> Otherwise we assign retval = _hardware_dequeue().

It is indeed a legitimate mistake on gcc's part.  Using
uninitialized_var() avoids generating unnecessary code to initialize the
value.  On the other hand, initializing to zero would keep future
possible changes from missing the warning.

Anyone know of a concensus on this kind of case?

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html