* Can I submit simple patches like this to the primary ML? @ 2015-01-29 3:48 Vinícius Tinti 2015-01-29 4:08 ` Greg KH 0 siblings, 1 reply; 7+ messages in thread From: Vinícius Tinti @ 2015-01-29 3:48 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-x86-LLVMLinux-Fix-uninitialized-function-do_reloc.patch Type: text/x-diff Size: 1065 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150129/55db914e/attachment-0001.bin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 3:48 Can I submit simple patches like this to the primary ML? Vinícius Tinti @ 2015-01-29 4:08 ` Greg KH 2015-01-29 4:16 ` Vinícius Tinti 0 siblings, 1 reply; 7+ messages in thread From: Greg KH @ 2015-01-29 4:08 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 4:08 ` Greg KH @ 2015-01-29 4:16 ` Vinícius Tinti 2015-01-29 5:07 ` Greg KH 0 siblings, 1 reply; 7+ messages in thread From: Vinícius Tinti @ 2015-01-29 4:16 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 4:16 ` Vinícius Tinti @ 2015-01-29 5:07 ` Greg KH 2015-01-29 11:27 ` Vinícius Tinti 0 siblings, 1 reply; 7+ messages in thread From: Greg KH @ 2015-01-29 5:07 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 5:07 ` Greg KH @ 2015-01-29 11:27 ` Vinícius Tinti 2015-01-29 11:39 ` Peter Senna Tschudin 2015-01-29 14:19 ` Greg KH 0 siblings, 2 replies; 7+ messages in thread From: Vinícius Tinti @ 2015-01-29 11:27 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 11:27 ` Vinícius Tinti @ 2015-01-29 11:39 ` Peter Senna Tschudin 2015-01-29 14:19 ` Greg KH 1 sibling, 0 replies; 7+ messages in thread From: Peter Senna Tschudin @ 2015-01-29 11:39 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150129/b15f1fbc/attachment-0001.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Can I submit simple patches like this to the primary ML? 2015-01-29 11:27 ` Vinícius Tinti 2015-01-29 11:39 ` Peter Senna Tschudin @ 2015-01-29 14:19 ` Greg KH 1 sibling, 0 replies; 7+ messages in thread From: Greg KH @ 2015-01-29 14:19 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-29 14:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-01-29 3:48 Can I submit simple patches like this to the primary ML? Vinícius Tinti 2015-01-29 4:08 ` Greg KH 2015-01-29 4:16 ` Vinícius Tinti 2015-01-29 5:07 ` Greg KH 2015-01-29 11:27 ` Vinícius Tinti 2015-01-29 11:39 ` Peter Senna Tschudin 2015-01-29 14:19 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).