Thread (7 messages) 7 messages, 3 authors, 2015-01-29

Can I submit simple patches like this to the primary ML?

From: Greg KH <hidden>
Date: 2015-01-29 05:07:54

On Thu, Jan 29, 2015 at 02:16:51AM -0200, Vin?cius Tinti wrote:
On Thu, Jan 29, 2015 at 2:08 AM, Greg KH [off-list ref] wrote:
quoted
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vin?cius Tinti wrote:
quoted
This is a simple patch that initializes a function with NULL to avoid some
compiler warnings. In such cases should I proceed as a normal patch or it is
better to send to another ML like to one for trivial patches?

Thanks,

Tinti
quoted
quoted
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <redacted>
Date: Thu, 29 Jan 2015 01:35:34 -0200
Subject: [PATCH] x86: LLVMLinux: Fix uninitialized function do_reloc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Explicit initializes do_reloc function with NULL. Later the function is
either proper initialized of an error issued.

Signed-off-by: Vin?cius Tinti <redacted>
---
 arch/x86/tools/relocs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 0c2fae8..1d533f1 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -971,7 +971,7 @@ static void emit_relocs(int as_text, int use_real_mode)
      int i;
      int (*write_reloc)(uint32_t, FILE *) = write32;
      int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
-                     const char *symname);
+                     const char *symname) = NULL;
I think you need to get an updated version of the compiler as this patch
should not be needed at all.  It doesn't cause a warning here for me
without it.
In fact it causes a warning on Clang which complains that:

   arch/x86/tools/relocs.c:977:6: warning: variable 'do_reloc' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
I suggest you file a bug with clang, gcc doesn't have this problem at
all as obviously, if you look at the code, that variable can never be
used uninitialized.
I think there is not a problem on the current code but to avoid
further problems I believe it is worth to initialize this function
with NULL.
What do you think?
Don't paper over bugs in the compiler with kernel code changes for no
good reason :)

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help