>> 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
On Tue, 2015-06-23 at 12:23 +0300, Dan Carpenter wrote:
> people decided that
> Yoda code was a good idea based on their gut instead of using statistics
> and measurements and science.
I think that style exists because compilers
disallow CONST = val assignment typos.
On Tue, 2015-06-23 at 12:57 +0300, Dan Carpenter wrote:
> I've never seen a real life proof that (!foo) code is less
> buggy.
Nor have I.
> 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
On Tue, 23 Jun 2015, Dan Carpenter wrote:
> 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 c
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
On Tue, 23 Jun 2015, Dan Carpenter wrote:
> On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote:
> > I've found in the past that developers can introduce bugs when they treat
> > return values as boolean when they really aren't.
>
> I can imagine a bug like that where a function can re
On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote:
> I've found in the past that developers can introduce bugs when they treat
> return values as boolean when they really aren't.
I can imagine a bug like that where a function can return 0-2 and people
do:
if (ret)
instead o
On 2015/06/20, 10:58 AM, "Julia Lawall" wrote:
>!x is more normal for kzalloc failure in the kernel.
While "!x" might be more normal for kzalloc(), I don't see that as an
improvement over explicitly checking against NULL, which is what kzalloc()
and other memory-allocating functions return on er
On Mon, Jun 22, 2015 at 05:27:03PM +, Simmons, James A. wrote:
>
> Is this change a hard requirement? Currently the lustre code standard in our
> development tree is the opposite policy.
Please follow the kernel coding style rules.
___
devel mailin
!x is more normal for kzalloc failure in the kernel.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression x;
statement S1, S2;
@@
x = kzalloc(...);
if (
- x == NULL
+ !x
) S1 else S2
//
Signed-off-by: Julia Lawall
---
drivers/staging/lustr
10 matches
Mail list logo
