Skip to contentSkip to conversation

trivial patches: Should we care about control reaches end of non-void function

PATCH New Steve Kemp 2 participants 4 messages Oct 15, 2008 – Oct 16, 2008

Subsystems (8)
Memory management x86 VFS Block layer +4 more subsystems
lore
Share & tools
lore

Steve Kemp

author
#0 lore raw

During my build processes I see a lot of messages like this:

In function xxx:
xxx.c:123: control reaches end of non-void function

These are typically caused by constructs like:

    static int some_function()
    {
        switch (blah) {
        ...

        default:
            BUG();
        }
    }

I see some functions in the kernel have added "return 0" after the
BUG, presumably to silence these warnings. Would a patch to do this consistently, or is that too trivial even for trivial patches?

Actual example:
./mm/mempolicy.c
policy_zonelist - gives this warning.
slab_node - gives this warning
__mpol_equal - has the warning silenced via explicit return.

Steve

Signature · 2 lines
Managed Anti-Spam Service
http://mail-scanning.com/
author
#1 lore raw

PATCH 1/1 compiler warning cleanup

This patch corrects the following gcc warning in several places:

warning: control reaches end of non-void function

It does this by adding harmless "return 0", or "return NULL", after the use of BUG().

My first kernel submission, be gentle with me ;)

Signed-off-by Steve Kemp <[email protected]>

---

arch/x86/kernel/genx2apic_uv_x.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/arch/x86/kernel/genx2apic_uv_x.c linux-2.6.27/arch/x86/kernel/genx2apic_uv_x.c
@@ -181,6 +181,7 @@ static __init int boot_pnode_to_blade(in
 		if (pnode == uv_blade_info[blade].pnode)
 			return blade;
 	BUG();
+        return 0;
 }
 
 struct redir_addr {
block/cfq-iosched.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/block/cfq-iosched.c linux-2.6.27/block/cfq-iosched.c
@@ -1497,6 +1497,7 @@ cfq_async_queue_prio(struct cfq_data *cf
 		return &cfqd->async_idle_cfqq;
 	default:
 		BUG();
+                return NULL;
 	}
 }
drivers/hwmon/adt7473.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/drivers/hwmon/adt7473.c linux-2.6.27/drivers/hwmon/adt7473.c
@@ -805,6 +805,7 @@ static ssize_t show_pwm_auto_temp(struct
 	}
 	/* shouldn't ever get here */
 	BUG();
+        return NULL;
 }
 
 static ssize_t set_pwm_auto_temp(struct device *dev,
drivers/hwmon/i5k_amb.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/drivers/hwmon/i5k_amb.c linux-2.6.27/drivers/hwmon/i5k_amb.c
@@ -481,6 +481,7 @@ static unsigned long i5k_channel_pci_id(
 		return PCI_DEVICE_ID_INTEL_5400_FBD0 + channel;
 	default:
 		BUG();
+                return 0;
 	}
 }
drivers/memstick/core/mspro_block.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/drivers/memstick/core/mspro_block.c linux-2.6.27/drivers/memstick/core/mspro_block.c
@@ -653,6 +653,7 @@ has_int_reg:
 
 	default:
 		BUG();
+                return 0;
 	}
 }
fs/dcache.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/fs/dcache.c linux-2.6.27/fs/dcache.c
@@ -1874,6 +1874,7 @@ out_nolock:
 shouldnt_be_hashed:
 	spin_unlock(&dcache_lock);
 	BUG();
+        return NULL;
 }
 
 static int prepend(char **buffer, int *buflen, const char *str, int namelen)
mm/bootmem.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/mm/bootmem.c linux-2.6.27/mm/bootmem.c
@@ -318,6 +318,7 @@ static int __init mark_bootmem(unsigned
 		pos = bdata->node_low_pfn;
 	}
 	BUG();
+        return 0;
 }
 
 /**
mm/mempolicy.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/mm/mempolicy.c linux-2.6.27/mm/mempolicy.c
@@ -1410,6 +1410,7 @@ unsigned slab_node(struct mempolicy *pol
 
 	default:
 		BUG();
+                return 0;
 	}
 }
net/rfkill/rfkill.c +1 -0
diff --ignore-space-change -uprN -X linux-2.6.27.orig/Documentation/dontdiff linux-2.6.27.orig/net/rfkill/rfkill.c linux-2.6.27/net/rfkill/rfkill.c
@@ -325,6 +325,7 @@ static const char *rfkill_get_type_str(e
 		return "wwan";
 	default:
 		BUG();
+                return NULL;
 	}
 }

Steve

Signature · 2 lines
Managed Anti-Spam Service
http://mail-scanning.com/
#2 lore raw
In reply to Steve Kemp
Quoted 3 lines

I see some functions in the kernel have added "return 0" after the
BUG, presumably to silence these warnings. Would a patch to do this consistently, or is that too trivial even for trivial patches?

Probably better to mark BUG() properly for the compiler.

If you can get __attribute((__noreturn__)) on the end of the BUG function somehow say

static inline void bug_off(void) __attribute((__noreturn__)) {};

and expanded that onto the end of the macro maybe it would shut up

Alan

author
#3 lore raw
Quoted 1 line · Alan Cox

Probably better to mark BUG() properly for the compiler.

Good idea.

It seems this was attempted previously:

     http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.0/0843.html

The patch needs some updating to move it into the current location,
but passes a compile test at least.

Steve

Signature · 2 lines
Managed Anti-Spam Service
http://mail-scanning.com/