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@xxxxxxxxxxxxxx> wrote:
>>
>>> Signed-off-by: Pavankumar Kondeti <pkondeti@xxxxxxxxxxxxxx>
>>> ---
>>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
