Fix gcc4 warning,

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.

@@ -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)) {

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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

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 <><

@@ -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
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Right. The behavior of gcc4 makes perfect sense, I would not call it a bug at all, even though it could still become smarter.

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
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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.

@@ -748,6 +748,9 @@ eexit_3:
 eexit_2:
 	put_filp(file);
 eexit_1:
+	/* Reference went uninitialized. */
+	*efd = 0;
+	*efile = NULL;
 	return error;
 }

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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.

@@ -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)

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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.

@@ -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) ;

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

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
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors