[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6faae35ac9a40de97d7c1a98ad94fa4@EXCHCS32.ornl.gov>
Date: Wed, 24 Jun 2015 20:14:04 +0000
From: "Simmons, James A." <simmonsja@...l.gov>
To: 'Julia Lawall' <julia.lawall@...6.fr>,
Dan Carpenter <dan.carpenter@...cle.com>
CC: "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Drokin, Oleg" <oleg.drokin@...el.com>,
"lustre-devel@...ts.lustre.org" <lustre-devel@...ts.lustre.org>
Subject: RE: [lustre-devel] [PATCH 01/12] staging: lustre: fid: Use !x to
check for kzalloc failure
>> 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.
>
>On today's linux-next, I find 3218 tests on the result of kmalloc etc
>using NULL and 14429 without, making 82% without. The complete semantic
>patch is shown below.
Most people doing something a certain way is not a technical argument. Usually
people do what they are taught. From most people's comments their seems to
be no technical reason to us one over another. I do have one technical reason not
to accept these patches. It is too easy to make a mistake and break things very badly.
I don't think it is worth the risk for a non-hard requirement.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists