[KJ] [PATCH] Fix gcc4 warning,

[KJ] [PATCH] Fix gcc4 warning,

[Jesse Millan]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]


This patch eliminates the warning that is generated when passing an
uninitialized variable to a function, and in that function it 'looks'
like you may read the contents.

In this case, the address of a local variable 'idx' is passed to the
function bvec_alloc_bs(). Inside bvec_alloc_bs(), it is possible that
no value will be assigned to idx, in which case the function immediately
returns null and does not go on to read it. Human eyes can see that its
safe. Initializing it doen not hurt and it gets rid of the compiler warning.

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 423 bytes --]

Signed-off-by: Jesse Millan <jessem@cs.pdx.edu>

--- linux-2.6.12-rc4/fs/bio.c~	2005-05-20 11:24:39.163613256 -0700
+++ linux-2.6.12-rc4/fs/bio.c	2005-05-20 11:25:35.242185201 -0700
@@ -159,7 +159,7 @@ struct bio *bio_alloc_bioset(unsigned in

 		bio_init(bio);
 		if (likely(nr_iovecs)) {
-			unsigned long idx;
+			unsigned long idx = 0;

 			bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, &idx, bs);
 			if (unlikely(!bvl)) {

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] [PATCH] Fix gcc4 warning,

[Alexey Dobriyan]

On Friday 20 May 2005 22:53, Jesse Millan wrote:
> This patch eliminates the warning that is generated when passing an
> uninitialized variable to a function, and in that function it 'looks'
> like you may read the contents.
> 
> In this case, the address of a local variable 'idx' is passed to the
> function bvec_alloc_bs(). Inside bvec_alloc_bs(), it is possible that
> no value will be assigned to idx, in which case the function immediately
> returns null and does not go on to read it. Human eyes can see that its
> safe.

I think this should go straight to http://gcc.gnu.org/bugzilla/enter_bug.cgi
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] [PATCH] Fix gcc4 warning,

[Arnd Bergmann]

On Freedag 20 Mai 2005 21:51, Jesse Millan wrote:
> 
> So, the compiler should be able to tell that either one of the two cases
> apply?
> 
> a: an assignment statement will be done on idx before its ever read
> 
> or
> 
> b: no assignment statement, control flow will never allow idx to be read

gcc is normally pretty good at detecting this. Since gcc-4.0, it 
appears to do more checking inside inline functions, where older
versions just assumed that a variable is initialized after a reference
to it is passed to an inline function.

I'd suggest fixing the inline function to always do this instead of
fixing the caller. After all, this needs to be fixed in the kernel,
even if future gcc versions become smarter about it gcc-4.0 will
continue to be used.

	Arnd <><

--- a/fs/bio.c	2005-03-29 03:42:37 +02:00
+++ b/fs/bio.c	2005-05-22 11:22:17 +02:00
@@ -90,6 +90,7 @@
 		case  65 ... 128: *idx = 4; break;
 		case 129 ... BIO_MAX_PAGES: *idx = 5; break;
 		default:
+			*idx = 0;
 			return NULL;
 	}
 	/*
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] [PATCH] Fix gcc4 warning,

[Arnd Bergmann]

On Sünndag 22 Mai 2005 20:33, Jesse Millan wrote:
> Its not easy to reproduce this warning in a simple program. And, I am
> not sure that it is a bug on gcc4's part. It looks like gcc4 emits the
> warning when it cannot prove beyond a shadow of doubt that the variable
> is initialized before use.

Right. The behavior of gcc4 makes perfect sense, I would not call it a
bug at all, even though it could still become smarter.
 
> In an effort to cut down on warnings, should these be fixed? It can go
> either way, the compiler should be smart enough and maybe it will be
> someday, or, do the initialization to get rid of a bunch of warnings.

As I said, they should be fixed in the kernel, the released compiler
won't go away any more so it doesn't matter if future compilers are
smarter than the current one.

	Arnd <><

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

[KJ] [PATCH] Fix gcc4 warning,

[Jesse Millan]

This patch eliminates the warning that is generated when passing a
reference of an uninitialized variable to a function where it possible
that the function will return without initializing that variable.

Thats a mouthful.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

[KJ] [PATCH] Fix gcc4 warning,

[Jesse Millan]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]


This patch eliminates the warning that is generated when passing a
reference of an uninitialized variable to a function where it possible
that the function will return without initializing that variable.

Might help I attach the patch.

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 347 bytes --]

Signed-off-by: Jesse Millan <jessem@cs.pdx.edu>

--- linux-2.6.12-rc4/fs/eventpoll.c~	2005-05-23 21:25:57.666594235 -0700
+++ linux-2.6.12-rc4/fs/eventpoll.c	2005-05-23 21:29:13.398503871 -0700
@@ -748,6 +748,9 @@ eexit_3:
 eexit_2:
 	put_filp(file);
 eexit_1:
+	/* Reference went uninitialized. */
+	*efd = 0;
+	*efile = NULL;
 	return error;
 }

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

[KJ] [PATCH] Fix gcc4 warning,

[Jesse Millan]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]


Same as the last. This patch eliminates the warning that is generated
when passing a reference of an uninitialized variable to a function
where it possible that the function will return without initializing
that variable.

The first execution path leaves both def and len uninitialized. The
second leaves len uninitialized. In both cases, initializing them when
they otherwise would not have been is close to pointless because they
would not get used anyway. The change is only to suppress the compiler
warning.

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 660 bytes --]

Signed-off-by: Jesse Millan <jessem@cs.pdx.edu>

--- linux-2.6.12-rc4/fs/cifs/asn1.c~	2005-05-24 22:25:21.436866468 -0700
+++ linux-2.6.12-rc4/fs/cifs/asn1.c	2005-05-24 22:49:43.744939729 -0700
@@ -160,12 +160,18 @@ asn1_length_decode(struct asn1_ctx *ctx,
 {
 	unsigned char ch, cnt;

-	if (!asn1_octet_decode(ctx, &ch))
+	if (!asn1_octet_decode(ctx, &ch)) {
+		/* Function would have returned without initializing 'def' and 'len' */
+		*def = 0;
+		*len = 0;
 		return 0;
+	}

-	if (ch == 0x80)
+	if (ch == 0x80) {
 		*def = 0;
-	else {
+		/* Function would have returned without initializing 'len' */
+		*len = 0;
+	} else {
 		*def = 1;

 		if (ch < 0x80)

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

[KJ] [PATCH] Fix gcc4 warning,

[Jesse Millan]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]


Same same. This patch eliminates the warning that is generated
when passing a reference of an uninitialized variable to a function
where it possible that the function will return without initializing
that variable.

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 615 bytes --]

Signed-off-by: Jesse Millan <jessem@cs.pdx.edu>

--- linux-2.6.12-rc4/fs/devfs/base.c~	2005-05-25 15:22:47.710055525 -0700
+++ linux-2.6.12-rc4/fs/devfs/base.c	2005-05-25 15:26:15.975096985 -0700
@@ -1127,8 +1127,11 @@ static devfs_handle_t _devfs_make_parent

 	if (dir == NULL)
 		dir = _devfs_get_root_entry();
-	if (dir == NULL)
+	if (dir == NULL) {
+		/* Function would have returned without initializing 'leaf_pos' */
+		*leaf_pos = 0;
 		return NULL;
+	}
 	devfs_get(dir);
 	/*  Search for possible trailing component and ignore it  */
 	for (--namelen; (namelen > 0) && (name[namelen] != '/'); --namelen) ;

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] [PATCH] Fix gcc4 warning,

[Arnd Bergmann]

On Middeweken 25 Mai 2005 21:18, Jesse Millan wrote:
> Your right, it could go either way. Arnd Bergmann had posted earlier and
> said that it would be better to make the change in the function itself.
> I took that advice.

I think what Mark was suggesting is to initialize the parameters at the
start of the inner function (asn1_length_decode), which makes perfect
sense to me, at least in this particular case.

What you should not do is initialize it in the calling function, because
then you defeat gcc's ability to warn you about real uninitialized uses
of the local variables in that function.

	Arnd <><
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors