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
Signed-off-by: Sheng Yang <[email protected]>
CC: Alan Cox <[email protected]>
---
drivers/serial/8250.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 303272a..c78eee6 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -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;
--
1.5.4.5
(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
Signed-off-by: Sheng Yang <[email protected]>
---
drivers/serial/8250.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 303272a..c78eee6 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -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;
--
1.5.4.5
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
On Tuesday 25 November 2008 18:22:30 Alan Cox wrote:
> 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.
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
Signed-off-by: Sheng Yang <[email protected]>
---
drivers/serial/8250.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 303272a..c3120be 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -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))
--
1.5.4.5
> 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.
> 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
On Tuesday 25 November 2008 18:43:34 Alan Cox wrote:
> > 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.
>
> > 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
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.
--
regards
Yang, Sheng
> The logic here is strange...
Why
> 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.
>
> 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
On Tue, Nov 25, 2008 at 06:51:44PM +0800, Sheng Yang wrote:
> 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.
> 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.
On Tuesday 25 November 2008 19:13:42 Alan Cox wrote:
> > The logic here is strange...
>
> Why
>
> > 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. :)
--
regards
Yang, Sheng
>
> > 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