Can I submit simple patches like this to the primary ML?
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
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote:
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
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <viniciustinti@gmail.com> 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 <viniciustinti@gmail.com> --- 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. thanks, greg k-h
On Thu, Jan 29, 2015 at 2:08 AM, Greg KH <greg@kroah.com> wrote:
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote:
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
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <viniciustinti@gmail.com> 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 <viniciustinti@gmail.com> --- 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 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?
thanks,
greg k-h
-- Simplicity is the ultimate sophistication
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 <greg@kroah.com> wrote:
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote:
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
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <viniciustinti@gmail.com> 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 <viniciustinti@gmail.com> --- 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
On Thu, Jan 29, 2015 at 3:07 AM, Greg KH <greg@kroah.com> wrote:
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 <greg@kroah.com> wrote:
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote:
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
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <viniciustinti@gmail.com> 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 <viniciustinti@gmail.com> --- 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 can simply turn down this kind of warning.
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 :)
Agreed. But whenever I find a warning in GCC during the build what should I do with it? Can I simply send it to the main ml?
thanks,
greg k-h
-- Simplicity is the ultimate sophistication
On Thu, Jan 29, 2015 at 12:27 PM, Vinícius Tinti <viniciustinti@gmail.com> wrote:
On Thu, Jan 29, 2015 at 3:07 AM, Greg KH <greg@kroah.com> wrote:
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 <greg@kroah.com> wrote:
On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote:
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
From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= <viniciustinti@gmail.com> 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 <viniciustinti@gmail.com> --- 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 can simply turn down this kind of warning.
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 :)
Agreed. But whenever I find a warning in GCC during the build what should I do with it? Can I simply send it to the main ml?
If you believe your patch is correct, and if checkpatch.pl doesn't complain about your patch, then get_maintainers.pl will tell you the people and mailing lists you should send your patch to.
thanks,
greg k-h
-- Simplicity is the ultimate sophistication
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Peter
On Thu, Jan 29, 2015 at 09:27:48AM -0200, Vinícius Tinti wrote:
On Thu, Jan 29, 2015 at 3:07 AM, Greg KH <greg@kroah.com> wrote:
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 can simply turn down this kind of warning.
Or you can send a bug report to the clang developers so they can fix it, which would be best in the end, right?
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 :)
Agreed. But whenever I find a warning in GCC during the build what should I do with it?
Depends on the specific warning, and what type of fix it requires. If you do see them, and you are running with the latest version of gcc, and the warning is for a problem that is real (hint, this problem was not real as the code showed), then yes, of course submit a patch for it.
Can I simply send it to the main ml?
Use the scripts/get_maintainer.pl tool on your patch to determine who to send it to and what mailing lists to copy. Hope this helps, greg k-h
participants (3)
-
Greg KH -
Peter Senna Tschudin -
Vinícius Tinti