All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Lambert <lambert.quentin@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, sparmaintainer@unisys.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	Benjamin Romer <benjamin.romer@unisys.com>,
	David Kershner <david.kershner@unisys.com>
Subject: Re: [PATCH 1/1] staging: unisys: Remove allocation from declaration line
Date: Thu, 12 Feb 2015 12:22:12 +0000	[thread overview]
Message-ID: <54DC9AF4.8050805@gmail.com> (raw)
In-Reply-To: <20150211102306.GB26542@mwanda>

On 11/02/2015 11:23, Dan Carpenter wrote:
> On Wed, Feb 11, 2015 at 06:26:27AM +0800, Greg Kroah-Hartman wrote:
>> On Tue, Feb 10, 2015 at 02:02:14PM +0100, Quentin Lambert wrote:
>>> This patch removes allocation from declaration line because
>>> people are known to gloss over declarations.
>> Again, who are these lazy people, and why are they reading kernel code?
>>
>  From my work with smatch:
> 1) Probably 70-80% of inconsistent NULL checking is when done in the
>     initializer.  I'm sending a patch for one of these today.
> 2) If there is an allocation in the initializer then it's more likely
>     that the NULL check will be missing.
> Initializers are a blind spot that people do not read.  It's not just
> one maintainer, it's consistent across the board.
>
> Also if you put an allocation in the initializer then it almost always
> has to be mangled to fit in 80 characters and it looks ugly.  But after
> these patches then all the allocations fit naturally.
>
> Plus you have to have that blank line to separate the initialization
> paragraph from the paragraph with the check for allocation failure.
>
> Really, it is fairly uncommon to put an allocation in the initalizer.
>
> regards,
> dan carpenter
In the case this patch wasn't accepted what should I do with
this one: https://lkml.org/lkml/2015/2/10/182 ?

Do you want me to submit a non-dependent version?

regards,
Quentin



WARNING: multiple messages have this Message-ID (diff)
From: Quentin Lambert <lambert.quentin@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, sparmaintainer@unisys.com,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	Benjamin Romer <benjamin.romer@unisys.com>,
	David Kershner <david.kershner@unisys.com>
Subject: Re: [PATCH 1/1] staging: unisys: Remove allocation from declaration line
Date: Thu, 12 Feb 2015 13:22:12 +0100	[thread overview]
Message-ID: <54DC9AF4.8050805@gmail.com> (raw)
In-Reply-To: <20150211102306.GB26542@mwanda>

On 11/02/2015 11:23, Dan Carpenter wrote:
> On Wed, Feb 11, 2015 at 06:26:27AM +0800, Greg Kroah-Hartman wrote:
>> On Tue, Feb 10, 2015 at 02:02:14PM +0100, Quentin Lambert wrote:
>>> This patch removes allocation from declaration line because
>>> people are known to gloss over declarations.
>> Again, who are these lazy people, and why are they reading kernel code?
>>
>  From my work with smatch:
> 1) Probably 70-80% of inconsistent NULL checking is when done in the
>     initializer.  I'm sending a patch for one of these today.
> 2) If there is an allocation in the initializer then it's more likely
>     that the NULL check will be missing.
> Initializers are a blind spot that people do not read.  It's not just
> one maintainer, it's consistent across the board.
>
> Also if you put an allocation in the initializer then it almost always
> has to be mangled to fit in 80 characters and it looks ugly.  But after
> these patches then all the allocations fit naturally.
>
> Plus you have to have that blank line to separate the initialization
> paragraph from the paragraph with the check for allocation failure.
>
> Really, it is fairly uncommon to put an allocation in the initalizer.
>
> regards,
> dan carpenter
In the case this patch wasn't accepted what should I do with
this one: https://lkml.org/lkml/2015/2/10/182 ?

Do you want me to submit a non-dependent version?

regards,
Quentin



  reply	other threads:[~2015-02-12 12:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 13:02 [PATCH 1/1] staging: unisys: Remove allocation from declaration line Quentin Lambert
2015-02-10 13:02 ` Quentin Lambert
2015-02-10 13:43 ` Sudip Mukherjee
2015-02-10 13:55   ` Sudip Mukherjee
2015-02-10 22:26 ` Greg Kroah-Hartman
2015-02-10 22:26   ` Greg Kroah-Hartman
2015-02-11 10:23   ` Dan Carpenter
2015-02-11 10:23     ` Dan Carpenter
2015-02-12 12:22     ` Quentin Lambert [this message]
2015-02-12 12:22       ` Quentin Lambert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DC9AF4.8050805@gmail.com \
    --to=lambert.quentin@gmail.com \
    --cc=benjamin.romer@unisys.com \
    --cc=dan.carpenter@oracle.com \
    --cc=david.kershner@unisys.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparmaintainer@unisys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.