From: Dan Carpenter <dan.carpenter@oracle.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Drokin, Oleg" <oleg.drokin@intel.com>,
"lustre-devel@lists.lustre.org" <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
Date: Tue, 23 Jun 2015 09:57:04 +0000 [thread overview]
Message-ID: <20150623095704.GO28762@mwanda> (raw)
In-Reply-To: <alpine.DEB.2.10.1506231127120.2554@hadrien>
Yes. I know Al's thoughts and kernel style.
But Alan Cox and Andreas have both said they think (x = NULL) can help
you avoid some kind of boolean vs pointer bugs. I've had co-workers who
did massive seds changing !foo to foo = NULL on our code base. But
I've never seen a real life example of a bug this fixes.
To be honest, I've never seen a real life proof that (!foo) code is less
buggy. I should look through the kbuild mailbox... Hm... But my other
idea of setting up code style readability testing website is also a good
one.
Linux kernel style is based on Joe Perches finding that 80% of the code
prefers one way or the other. That's a valid method for determining
code style. I bet it normally picks the more readable style but it
would be interesting to measure it more formally.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
Date: Tue, 23 Jun 2015 12:57:04 +0300 [thread overview]
Message-ID: <20150623095704.GO28762@mwanda> (raw)
In-Reply-To: <alpine.DEB.2.10.1506231127120.2554@hadrien>
Yes. I know Al's thoughts and kernel style.
But Alan Cox and Andreas have both said they think (x == NULL) can help
you avoid some kind of boolean vs pointer bugs. I've had co-workers who
did massive seds changing !foo to foo == NULL on our code base. But
I've never seen a real life example of a bug this fixes.
To be honest, I've never seen a real life proof that (!foo) code is less
buggy. I should look through the kbuild mailbox... Hm... But my other
idea of setting up code style readability testing website is also a good
one.
Linux kernel style is based on Joe Perches finding that 80% of the code
prefers one way or the other. That's a valid method for determining
code style. I bet it normally picks the more readable style but it
would be interesting to measure it more formally.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Drokin, Oleg" <oleg.drokin@intel.com>,
"lustre-devel@lists.lustre.org" <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure
Date: Tue, 23 Jun 2015 12:57:04 +0300 [thread overview]
Message-ID: <20150623095704.GO28762@mwanda> (raw)
In-Reply-To: <alpine.DEB.2.10.1506231127120.2554@hadrien>
Yes. I know Al's thoughts and kernel style.
But Alan Cox and Andreas have both said they think (x == NULL) can help
you avoid some kind of boolean vs pointer bugs. I've had co-workers who
did massive seds changing !foo to foo == NULL on our code base. But
I've never seen a real life example of a bug this fixes.
To be honest, I've never seen a real life proof that (!foo) code is less
buggy. I should look through the kbuild mailbox... Hm... But my other
idea of setting up code style readability testing website is also a good
one.
Linux kernel style is based on Joe Perches finding that 80% of the code
prefers one way or the other. That's a valid method for determining
code style. I bet it normally picks the more readable style but it
would be interesting to measure it more formally.
regards,
dan carpenter
next prev parent reply other threads:[~2015-06-23 9:57 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-20 16:58 [PATCH 00/12] Use !x to check for kzalloc failure Julia Lawall
2015-06-20 16:58 ` Julia Lawall
2015-06-20 16:58 ` [PATCH 01/12] staging: lustre: fid: " Julia Lawall
2015-06-20 16:58 ` Julia Lawall
2015-06-22 15:46 ` [lustre-devel] Fwd: [HPDD-discuss] " Patrick Farrell
2015-06-22 17:18 ` Simmons, James A.
2015-06-23 8:05 ` Dilger, Andreas
2015-06-23 8:25 ` Dilger, Andreas
2015-06-23 8:25 ` Dilger, Andreas
2015-06-23 8:25 ` [lustre-devel] " Dilger, Andreas
2015-06-23 9:23 ` Dan Carpenter
2015-06-23 9:23 ` Dan Carpenter
2015-06-23 9:23 ` [lustre-devel] " Dan Carpenter
2015-06-23 9:35 ` Julia Lawall
2015-06-23 9:35 ` Julia Lawall
2015-06-23 9:35 ` [lustre-devel] " Julia Lawall
2015-06-23 9:57 ` Dan Carpenter [this message]
2015-06-23 9:57 ` Dan Carpenter
2015-06-23 9:57 ` [lustre-devel] " Dan Carpenter
2015-06-23 10:51 ` Julia Lawall
2015-06-23 10:51 ` Julia Lawall
2015-06-23 10:51 ` [lustre-devel] " Julia Lawall
2015-06-24 20:14 ` Simmons, James A.
2015-06-24 20:14 ` Simmons, James A.
2015-06-24 20:14 ` Simmons, James A.
2015-06-23 22:03 ` Joe Perches
2015-06-23 22:03 ` Joe Perches
2015-06-23 22:03 ` [lustre-devel] " Joe Perches
2015-06-23 22:11 ` Joe Perches
2015-06-23 22:11 ` Joe Perches
2015-06-23 22:11 ` [lustre-devel] " Joe Perches
2015-06-28 6:52 ` LIBCFS_ALLOC Julia Lawall
2015-06-28 6:52 ` LIBCFS_ALLOC Julia Lawall
2015-06-28 6:52 ` [lustre-devel] LIBCFS_ALLOC Julia Lawall
2015-06-28 21:54 ` LIBCFS_ALLOC Dan Carpenter
2015-06-28 21:54 ` LIBCFS_ALLOC Dan Carpenter
2015-06-28 21:54 ` [lustre-devel] LIBCFS_ALLOC Dan Carpenter
2015-06-30 14:56 ` LIBCFS_ALLOC Simmons, James A.
2015-06-30 14:56 ` [lustre-devel] LIBCFS_ALLOC Simmons, James A.
2015-06-30 15:01 ` LIBCFS_ALLOC Julia Lawall
2015-06-30 15:01 ` LIBCFS_ALLOC Julia Lawall
2015-06-30 15:01 ` [lustre-devel] LIBCFS_ALLOC Julia Lawall
2015-07-02 22:25 ` Simmons, James A.
2015-07-02 22:25 ` Simmons, James A.
2015-07-02 22:25 ` Simmons, James A.
2015-07-03 11:52 ` Dilger, Andreas
2015-07-03 11:52 ` Dilger, Andreas
2015-07-03 11:52 ` Dilger, Andreas
2015-06-30 17:38 ` LIBCFS_ALLOC Dan Carpenter
2015-06-30 17:38 ` LIBCFS_ALLOC Dan Carpenter
2015-06-30 17:38 ` [lustre-devel] LIBCFS_ALLOC Dan Carpenter
2015-06-30 21:26 ` Dilger, Andreas
2015-06-30 21:26 ` Dilger, Andreas
2015-06-20 16:59 ` [PATCH 02/12] staging: lustre: fld: Use !x to check for kzalloc failure Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 03/12] staging: lustre: lclient: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 04/12] staging: lustre: ldlm: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 05/12] staging: lustre: lmv: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 06/12] staging: lustre: lov: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 07/12] staging: lustre: mdc: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 08/12] staging: lustre: mgc: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 09/12] staging: lustre: obdclass: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-21 10:02 ` walter harms
2015-06-21 10:02 ` walter harms
2015-06-21 10:29 ` Julia Lawall
2015-06-21 10:29 ` Julia Lawall
2015-06-21 11:58 ` walter harms
2015-06-20 16:59 ` [PATCH 10/12] staging: lustre: obdecho: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 11/12] staging: lustre: osc: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
2015-06-20 16:59 ` [PATCH 12/12] staging: lustre: ptlrpc: " Julia Lawall
2015-06-20 16:59 ` Julia Lawall
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=20150623095704.GO28762@mwanda \
--to=dan.carpenter@oracle.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.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.