Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1710299 > unrolled thread

Re: [PATCH] New Chapter on CodingStyle .

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH]  New Chapter on CodingStyle . Jonathan Corbet <corbet@lwn.net> - 2017-08-12 17:00 +0200
    RE: [PATCH]  New Chapter on CodingStyle . David Laight <David.Laight@ACULAB.COM> - 2017-08-15 12:50 +0200
      Re: [PATCH]  New Chapter on CodingStyle . Stephen Hemminger <stephen@networkplumber.org> - 2017-08-15 18:30 +0200
        RE: [PATCH]  New Chapter on CodingStyle . David Laight <David.Laight@ACULAB.COM> - 2017-08-15 19:00 +0200

#1710299 — Re: [PATCH] New Chapter on CodingStyle .

On Sat, 12 Aug 2017 14:23:18 +0300
Corcodel Marian <asd@marian1000.go.ro> wrote:

> ---
>  Documentation/CodingStyle | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index 9a70ddd..864dd8b 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -922,6 +922,34 @@ expression used.  For instance:
>  	...
>  	#endif /* CONFIG_SOMETHING */
>  
> +		Chapter 20: Put values on initialisers without exception
> +
> +When declaring variables on functions must put values:

Thanks for sending a patch for the kernel's documentation.
Unfortunately, I can't accept this patch for a couple of reasons:

- Kernel patches must include a changelog describing *why* the change is
  being made and a proper signoff line.  See
  Documentation/process/submitting-patches.rst for details.

- The coding style document is there to describe the community's
  standards for kernel code.  It is *not* a mechanism for imposing new
  standards.  If you really think that the kernel community should adopt
  this rule, you will need to argue for it on the mailing lists.  I will
  say, though, that I do not expect that this effort would be successful.

Can I make a suggestion?  If you have found kernel functions with bugs
related to use of uninitialized variables, please submit fixes for those
specific bugs, along with a clear description of how the bug happens and
what its effects are.

Thanks,

jon

[toc] | [next] | [standalone]

#1712063

From: Jonathan Corbet
> Sent: 12 August 2017 15:55
...
> > +		Chapter 20: Put values on initialisers without exception
> > +
> > +When declaring variables on functions must put values:
> 
> Thanks for sending a patch for the kernel's documentation.
> Unfortunately, I can't accept this patch for a couple of reasons:
...
> - The coding style document is there to describe the community's
>   standards for kernel code.  It is *not* a mechanism for imposing new
>   standards.  If you really think that the kernel community should adopt
>   this rule, you will need to argue for it on the mailing lists.  I will
>   say, though, that I do not expect that this effort would be successful.

I'd even go as far as suggesting almost the opposite.
Declarations should only have initialisers if the value is constant.

	David

[toc] | [prev] | [next] | [standalone]

#1712315

On Tue, 15 Aug 2017 10:42:39 +0000
David Laight <David.Laight@ACULAB.COM> wrote:

> From: Jonathan Corbet
> > Sent: 12 August 2017 15:55  
> ...
> > > +		Chapter 20: Put values on initialisers without exception
> > > +
> > > +When declaring variables on functions must put values:  
> > 
> > Thanks for sending a patch for the kernel's documentation.
> > Unfortunately, I can't accept this patch for a couple of reasons:  
> ...
> > - The coding style document is there to describe the community's
> >   standards for kernel code.  It is *not* a mechanism for imposing new
> >   standards.  If you really think that the kernel community should adopt
> >   this rule, you will need to argue for it on the mailing lists.  I will
> >   say, though, that I do not expect that this effort would be successful.  
> 
> I'd even go as far as suggesting almost the opposite.
> Declarations should only have initialisers if the value is constant.

Yup. This new rule sound like something taught to people in coding schools.
But initializing everything defeats the compiler detection of uninitialized variables
which is more useful for catching errors.

[toc] | [prev] | [next] | [standalone]

#1712347

From: Stephen Hemminger
> Sent: 15 August 2017 17:21
> On Tue, 15 Aug 2017 10:42:39 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
> 
> > From: Jonathan Corbet
> > > Sent: 12 August 2017 15:55
> > ...
> > > > +		Chapter 20: Put values on initialisers without exception
> > > > +
> > > > +When declaring variables on functions must put values:
> > >
> > > Thanks for sending a patch for the kernel's documentation.
> > > Unfortunately, I can't accept this patch for a couple of reasons:
> > ...
> > > - The coding style document is there to describe the community's
> > >   standards for kernel code.  It is *not* a mechanism for imposing new
> > >   standards.  If you really think that the kernel community should adopt
> > >   this rule, you will need to argue for it on the mailing lists.  I will
> > >   say, though, that I do not expect that this effort would be successful.
> >
> > I'd even go as far as suggesting almost the opposite.
> > Declarations should only have initialisers if the value is constant.
> 
> Yup. This new rule sound like something taught to people in coding schools.
> But initializing everything defeats the compiler detection of uninitialized variables
> which is more useful for catching errors.

You'll also get:
Values being read the wrong side of locks.
Values being read early so requiring spilling to stack.

Next someone will be suggesting that all pointers should be checked
against NULL every time they are used.

	David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web