8250: Eliminate compile warning of 8250.c
PATCH 1/1 8250: Eliminate compile warning of 8250.c
The patch based on linux-2.6 upstream and elimiate this compile warning info:
drivers/serial/8250.c: In function ‘serial8250_shutdown’:drivers/serial/8250.c:1612: warning: ‘i’ may be used uninitialized in this function
--- drivers/serial/8250.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/serial/8250.c +1 -1
@@ -1609,7 +1609,7 @@ static int serial_link_irq_chain(struct uart_8250_port *up)static void serial_unlink_irq_chain (struct uart_8250_port *up) { -struct irq_info *i; +struct irq_info *i =NULL ;struct hlist_node *n;struct hlist_head *h;
Signature · 6 lines
1.5.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/1 8250: Eliminate compile warning of 8250.c
(Something wrong with encoding of the first mail...)
The patch based on linux-2.6 upstream and elimiate this compile warning info:
drivers/serial/8250.c: In function 'serial8250_shutdown':drivers/serial/8250.c:1612: warning: 'i' may be used uninitialized in this function
--- drivers/serial/8250.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/serial/8250.c +1 -1
@@ -1609,7 +1609,7 @@ static int serial_link_irq_chain(struct uart_8250_port *up)static void serial_unlink_irq_chain (struct uart_8250_port *up) { -struct irq_info *i; +struct irq_info *i =NULL ;struct hlist_node *n;struct hlist_head *h;
Signature · 1 line
1.5.4.5
Alan Cox
NAKQuoted 8 lines · On Tue, 25 Nov 2008 11:58:23 +0800 Sheng Yang <[email protected]> wrote:
(Something wrong with encoding of the first mail...)
The patch based on linux-2.6 upstream and elimiate this compile warning info:
drivers/serial/8250.c: In function 'serial8250_shutdown':drivers/serial/8250.c:1612: warning: 'i' may be used uninitialized in this function
NAK - again.
There is no real bug here and you risk hiding future ones. It also doesn't produce a warning with a modern gcc.
Alan
Quoted 8 lines · On Tuesday 25 November 2008 18:22:30 Alan Cox wrote:
On Tue, 25 Nov 2008 11:58:23 +0800
Quoted 5 lines · Sheng Yang
(Something wrong with encoding of the first mail...)
The patch based on linux-2.6 upstream and elimiate this compile warning info:
Quoted 8 lines
Quoted 3 lines
drivers/serial/8250.c: In function 'serial8250_shutdown':drivers/serial/8250.c:1612: warning: 'i' may be used uninitialized in this functionNAK - again.
There is no real bug here and you risk hiding future ones. It also doesn't produce a warning with a modern gcc.
Can't understand initializing got "risk hiding future ones". As I know, didn't initialize the variable got risk hiding future random problems. If you think i=NULL is not enough, how about this? I don't use this version just because I think BUG_ON(n==null) cover this. And I don't think leave it to compiler is more proper here.
--
From: Sheng Yang <[email protected]>
Date: Tue, 25 Nov 2008 18:25:26 +0800
Subject: [PATCH 1/1] 8250: Eliminate compile warning of 8250.c
The patch based on linux-2.6 upstream and elimiate this compile warning info:
drivers/serial/8250.c: In function 'serial8250_shutdown':drivers/serial/8250.c:1612: warning: 'i' may be used uninitialized in this function
--- drivers/serial/8250.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/serial/8250.c +0 -0
@@ -1609,7 +1609,7 @@ static int serial_link_irq_chain(struct uart_8250_port
*up)
static void serial_unlink_irq_chain(struct uart_8250_port *up) {
- struct irq_info *i;
+ struct irq_info *i = NULL;
struct hlist_node *n;
struct hlist_head *h;
@@ -1624,6 +1624,7 @@ static void serial_unlink_irq_chain(struct uart_8250_port *up)
}
BUG_ON(n == NULL);
+ BUG_ON(i == NULL);
BUG_ON(i->head == NULL);
if (list_empty(i->head))
Signature · 1 line
1.5.4.5
Quoted 1 line
Can't understand initializing got "risk hiding future ones". As I know, didn't
Because if you set it to NULL and later delete a line which does the intended assignment you will no longer get a warning.
Quoted 2 lines
think
BUG_ON(n==null)cover this. And I don't think leave it to compiler is more proper here.
The BUG_ON covers it, the current gcc gets this right and works it out.
NAK again
Quoted 6 lines · On Tuesday 25 November 2008 18:43:34 Alan Cox wrote:
Quoted 2 lines
Can't understand initializing got "risk hiding future ones". As I know, didn't
Because if you set it to NULL and later delete a line which does the intended assignment you will no longer get a warning.
Quoted 6 lines
Quoted 2 lines
think
BUG_ON(n==null)cover this. And I don't think leave it to compiler is more proper here.The
BUG_ONcovers it, the current gcc gets this right and works it out.NAK again
The logic here is strange...
If you used old compiler, you would get a warning, and you thought that's ensured we won't delete a intended assignment by mistake.
If you used new compiler, you wouldn't get a warning, and you think this time the compiler get it right.
So, what result did you expect? A warning to notice that we didn't delete a intended assignment, or a "right" result?
OK. if you worry about "delete a line which does the intended assignment", the updated version with BUG_ON(i == NULL) can help.
Signature · 2 lines
regards Yang, Sheng
Quoted 1 line
The logic here is strange...
Why
Quoted 2 lines
If you used old compiler, you would get a warning, and you thought that's ensured we won't delete a intended assignment by mistake.
No.. if you hid the warning by hacking around the compiler mistake with extra bogus assignments you would hide a future mistake.
Quoted 3 lines
If you used new compiler, you wouldn't get a warning, and you think this time the compiler get it right.
The compiler does now get it right - I checked.
Alan
Quoted 9 lines · On Tuesday 25 November 2008 19:13:42 Alan Cox wrote:
Quoted 1 line
The logic here is strange...
Why
Quoted 2 lines
If you used old compiler, you would get a warning, and you thought that's ensured we won't delete a intended assignment by mistake.
No.. if you hid the warning by hacking around the compiler mistake with extra bogus assignments you would hide a future mistake.
OK, I got it now.
Comparing the result of deleting a meaningful line, this modification result in no more warning. And you also think one additional BUG_ON just for fixing compiler's mistake, so it's unacceptable.
So leave the patch as it was. Seems many people need to upgrade compiler to avoid this thing. :)
Signature · 2 lines
regards Yang, Sheng
Quoted 7 lines
Quoted 3 lines
If you used new compiler, you wouldn't get a warning, and you think this time the compiler get it right.
The compiler does now get it right - I checked.
Alan
Quoted 7 lines · Sheng Yang
The logic here is strange...
If you used old compiler, you would get a warning, and you thought that's ensured we won't delete a intended assignment by mistake.
If you used new compiler, you wouldn't get a warning, and you think this time the compiler get it right.
The new compiler gets it right. If you delete the assignment with the new compiler, *then* you get a warning.
Quoted 2 lines
OK. if you worry about "delete a line which does the intended assignment", the updated version with
BUG_ON(i == NULL)can help.
Compile-time error detection is better than runtime.
OG.