uvc_driver: fix compile warning

PATCH In review Alexey Klimov 3 participants 5 messages Apr 19, 2009 – Apr 20, 2009 Media (V4L/DVB)

lore

Share & tools

lore

Alexey Klimov

author

2009-04-19 20:03 UTC #0 lore raw

PATCH 1/1 uvc_driver: fix compile warning

Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?

Signed-off-by Alexey Klimov <[email protected]>

linux/drivers/media/video/uvc/uvc_driver.c +1 -1

diff -r cda79523a93c linux/drivers/media/video/uvc/uvc_driver.c
@@ -1726,7 +1726,7 @@
 static int __uvc_resume(struct usb_interface *intf, int reset)
 {
 	struct uvc_device *dev = usb_get_intfdata(intf);
-	int ret;
+	int ret = 0;
 
 	uvc_trace(UVC_TRACE_SUSPEND, "Resuming interface %u\n",
 		intf->cur_altsetting->desc.bInterfaceNumber);

Signature · 1 line

Best regards, Klimov Alexey

Laurent Pinchart

2009-04-20 17:32 UTC #1 lore raw

Hi Alexey,

Quoted 3 lines · On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote:

Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?

I can't reproduce the problem with gcc 4.3.2.

Hans, what's the policy for fixing gcc-related issues ? Should the code use uninitialized_var() to make every gcc version happy, or can ignore the warnings when a newer gcc version fixes the problem

Quoted 9 lines

Signed-off-by Alexey Klimov <[email protected]>
--
diff -r cda79523a93c linux/drivers/media/video/uvc/uvc_driver.c
--- a/linux/drivers/media/video/uvc/uvc_driver.c Thu Apr 16 18:30:38 2009
+0200 +++ b/linux/drivers/media/video/uvc/uvc_driver.c Sun Apr 19 23:58:02
2009 +0400 @@ -1726,7 +1726,7 @@
static int __uvc_resume(struct usb_interface *intf, int reset) {

linux/drivers/media/video/uvc/uvc_driver.c line 1732

Quoted 6 lines

linux/drivers/media/video/uvc/uvc_driver.c +1 -1

 	struct uvc_device *dev = usb_get_intfdata(intf);
-	int ret;
+	int ret = 0;
 
 	uvc_trace(UVC_TRACE_SUSPEND, "Resuming interface %u\n",
 		intf->cur_altsetting->desc.bInterfaceNumber);

Laurent Pinchart

Mauro Carvalho Chehab

2009-04-20 17:50 UTC #2 lore raw

Quoted 7 lines · On Mon, 20 Apr 2009 19:25:00 +0200 Laurent Pinchart…

Hi Alexey,
Quoted 3 lines · On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote:
Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?

Quoted 5 lines

I can't reproduce the problem with gcc 4.3.2.
Hans, what's the policy for fixing gcc-related issues ? Should the code use uninitialized_var() to make every gcc version happy, or can ignore the warnings when a newer gcc version fixes the problem

Laurent,

The kernel way is to use unitialized_var() on such cases.

Personally, I don't like very much this approach, since it will get rid forever of such error for that var. However, a future patch could make that var truly uninitialized. So, an extra care should be taken on every patch touching a var that uses uninitialized_var() macro.

Quoted 1 line

From my side, I accept patches with both ways to fix it.

Cheers,
Mauro

Laurent Pinchart

2009-04-20 20:10 UTC #3 lore raw

Hi Mauro,

Quoted 18 lines · On Monday 20 April 2009 19:50:31 Mauro Carvalho Chehab wrote:

On Mon, 20 Apr 2009 19:25:00 +0200
Quoted 7 lines · Laurent Pinchart
Hi Alexey,
Quoted 3 lines · On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote:
Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?
Quoted 5 lines
I can't reproduce the problem with gcc 4.3.2.
Hans, what's the policy for fixing gcc-related issues ? Should the code use uninitialized_var() to make every gcc version happy, or can ignore the warnings when a newer gcc version fixes the problem
Laurent,

Quoted 8 lines

The kernel way is to use unitialized_var() on such cases.
Personally, I don't like very much this approach, since it will get rid forever of such error for that var. However, a future patch could make that var truly uninitialized. So, an extra care should be taken on every patch touching a var that uses uninitialized_var() macro.
From my side, I accept patches with both ways to fix it.

I wasn't talking about ' = 0' vs. 'uninitialized_var()', but rather about submitting a patch vs. considering the problem fixed because gcc 4.3.2 doesn't spit a warning while gcc 4.3.1 does.

Cheers,

Laurent Pinchart

Mauro Carvalho Chehab

2009-04-20 20:47 UTC #4 lore raw

Quoted 28 lines · On Mon, 20 Apr 2009 22:12:47 +0200 Laurent Pinchart…

Hi Mauro,
Quoted 25 lines · On Monday 20 April 2009 19:50:31 Mauro Carvalho Chehab wrote:
On Mon, 20 Apr 2009 19:25:00 +0200
Quoted 7 lines · Laurent Pinchart
Hi Alexey,
Quoted 3 lines · On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote:
Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?
Quoted 5 lines
I can't reproduce the problem with gcc 4.3.2.
Hans, what's the policy for fixing gcc-related issues ? Should the code use uninitialized_var() to make every gcc version happy, or can ignore the warnings when a newer gcc version fixes the problem
Laurent,
The kernel way is to use unitialized_var() on such cases.
Personally, I don't like very much this approach, since it will get rid forever of such error for that var. However, a future patch could make that var truly uninitialized. So, an extra care should be taken on every patch touching a var that uses uninitialized_var() macro.

Quoted 5 lines

Quoted 1 line
From my side, I accept patches with both ways to fix it.
I wasn't talking about ' = 0' vs. 'uninitialized_var()', but rather about submitting a patch vs. considering the problem fixed because gcc 4.3.2 doesn't spit a warning while gcc 4.3.1 does.

Since 4.3.1 is a supported gcc version, it is better to fix the warning for it.

Cheers,
Mauro