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

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

[Vinícius Tinti]

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 

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

[Greg KH]

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

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

[Vinícius Tinti]

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

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

[Greg KH]

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

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

[Vinícius Tinti]

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

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

[Peter Senna Tschudin]

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 

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

[Greg KH]

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