public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* trivial patches: Should we care about control reaches end of non-void function
@ 2008-10-15 18:07 Steve Kemp
  2008-10-15 21:33 ` [PATCH] compiler warning cleanup Steve Kemp
  2008-10-15 22:26 ` trivial patches: Should we care about control reaches end of non-void function Alan Cox
  0 siblings, 2 replies; 4+ messages in thread
From: Steve Kemp @ 2008-10-15 18:07 UTC (permalink / raw)
  To: linux-kernel

  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
-- 
Managed Anti-Spam Service
http://mail-scanning.com/


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH] compiler warning cleanup
  2008-10-15 18:07 trivial patches: Should we care about control reaches end of non-void function Steve Kemp
@ 2008-10-15 21:33 ` Steve Kemp
  2008-10-15 22:26 ` trivial patches: Should we care about control reaches end of non-void function Alan Cox
  1 sibling, 0 replies; 4+ messages in thread
From: Steve Kemp @ 2008-10-15 21:33 UTC (permalink / raw)
  To: linux-kernel; +Cc: trivial


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 <steve@steve.org.uk>

---


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
--- linux-2.6.27.orig/arch/x86/kernel/genx2apic_uv_x.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/arch/x86/kernel/genx2apic_uv_x.c	2008-10-15 22:25:23.000000000 +0100
@@ -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 {
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
--- linux-2.6.27.orig/block/cfq-iosched.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/block/cfq-iosched.c	2008-10-15 22:25:39.000000000 +0100
@@ -1497,6 +1497,7 @@ cfq_async_queue_prio(struct cfq_data *cf
 		return &cfqd->async_idle_cfqq;
 	default:
 		BUG();
+                return NULL;
 	}
 }

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
--- linux-2.6.27.orig/drivers/hwmon/adt7473.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/drivers/hwmon/adt7473.c	2008-10-15 22:25:54.000000000 +0100
@@ -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,
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
--- linux-2.6.27.orig/drivers/hwmon/i5k_amb.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/drivers/hwmon/i5k_amb.c	2008-10-15 22:26:07.000000000 +0100
@@ -481,6 +481,7 @@ static unsigned long i5k_channel_pci_id(
 		return PCI_DEVICE_ID_INTEL_5400_FBD0 + channel;
 	default:
 		BUG();
+                return 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
--- linux-2.6.27.orig/drivers/memstick/core/mspro_block.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/drivers/memstick/core/mspro_block.c	2008-10-15 22:26:25.000000000 +0100
@@ -653,6 +653,7 @@ has_int_reg:

 	default:
 		BUG();
+                return 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
--- linux-2.6.27.orig/fs/dcache.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/fs/dcache.c	2008-10-15 22:26:42.000000000 +0100
@@ -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)
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
--- linux-2.6.27.orig/mm/bootmem.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/mm/bootmem.c	2008-10-15 22:26:57.000000000 +0100
@@ -318,6 +318,7 @@ static int __init mark_bootmem(unsigned
 		pos = bdata->node_low_pfn;
 	}
 	BUG();
+        return 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
--- linux-2.6.27.orig/mm/mempolicy.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/mm/mempolicy.c	2008-10-15 22:27:13.000000000 +0100
@@ -1410,6 +1410,7 @@ unsigned slab_node(struct mempolicy *pol

 	default:
 		BUG();
+                return 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
--- linux-2.6.27.orig/net/rfkill/rfkill.c	2008-10-09 23:13:53.000000000 +0100
+++ linux-2.6.27/net/rfkill/rfkill.c	2008-10-15 22:27:28.000000000 +0100
@@ -325,6 +325,7 @@ static const char *rfkill_get_type_str(e
 		return "wwan";
 	default:
 		BUG();
+                return NULL;
 	}
 }




Steve
-- 
Managed Anti-Spam Service
http://mail-scanning.com/


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: trivial patches: Should we care about control reaches end of non-void function
  2008-10-15 18:07 trivial patches: Should we care about control reaches end of non-void function Steve Kemp
  2008-10-15 21:33 ` [PATCH] compiler warning cleanup Steve Kemp
@ 2008-10-15 22:26 ` Alan Cox
  2008-10-16  6:08   ` Steve Kemp
  1 sibling, 1 reply; 4+ messages in thread
From: Alan Cox @ 2008-10-15 22:26 UTC (permalink / raw)
  To: Steve Kemp; +Cc: linux-kernel

>   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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: trivial patches: Should we care about control reaches end of non-void function
  2008-10-15 22:26 ` trivial patches: Should we care about control reaches end of non-void function Alan Cox
@ 2008-10-16  6:08   ` Steve Kemp
  0 siblings, 0 replies; 4+ messages in thread
From: Steve Kemp @ 2008-10-16  6:08 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

On Wed Oct 15, 2008 at 23:26:25 +0100, Alan Cox wrote:

> 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
-- 
Managed Anti-Spam Service
http://mail-scanning.com/


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-10-16  6:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-15 18:07 trivial patches: Should we care about control reaches end of non-void function Steve Kemp
2008-10-15 21:33 ` [PATCH] compiler warning cleanup Steve Kemp
2008-10-15 22:26 ` trivial patches: Should we care about control reaches end of non-void function Alan Cox
2008-10-16  6:08   ` Steve Kemp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox