[patch -next] mv643xx_eth: potential null dereference

[patch -next] mv643xx_eth: potential null dereference

[Dan Carpenter]

We assume that "pd" can be null on the previous line, and throughout the
function so we should check it here as well.  This was introduced by
9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 2fcdb1e..9166f55 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2675,7 +2675,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 	 * Detect hardware parameters.
 	 */
 	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
-	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
+	msp->tx_csum_limit = (pd && pd->tx_csum_limit) ?
+					pd->tx_csum_limit : 9 * 1024;
 	infer_hw_params(msp);
 
 	platform_set_drvdata(pdev, msp);

[patch -next] mv643xx_eth: potential null dereference

[Dan Carpenter]

We assume that "pd" can be null on the previous line, and throughout the
function so we should check it here as well.  This was introduced by
9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 2fcdb1e..9166f55 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2675,7 +2675,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 	 * Detect hardware parameters.
 	 */
 	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
-	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
+	msp->tx_csum_limit = (pd && pd->tx_csum_limit) ?
+					pd->tx_csum_limit : 9 * 1024;
 	infer_hw_params(msp);
 
 	platform_set_drvdata(pdev, msp);

Re: [patch -next] mv643xx_eth: potential null dereference

[Joe Perches]

On Fri, 2010-07-23 at 12:15 +0200, Dan Carpenter wrote:
> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
> index 2fcdb1e..9166f55 100644
> --- a/drivers/net/mv643xx_eth.c
> +++ b/drivers/net/mv643xx_eth.c
> @@ -2675,7 +2675,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  	 * Detect hardware parameters.
>  	 */
>  	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> -	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> +	msp->tx_csum_limit = (pd && pd->tx_csum_limit) ?
> +					pd->tx_csum_limit : 9 * 1024;

It's odd using two different check styles for the same
test on consecutive lines.

How about using the same style:

	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
					pd->tx_csum_limit : 9 * 1024;

Re: [patch -next] mv643xx_eth: potential null dereference

[Joe Perches]

On Fri, 2010-07-23 at 12:15 +0200, Dan Carpenter wrote:
> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
> index 2fcdb1e..9166f55 100644
> --- a/drivers/net/mv643xx_eth.c
> +++ b/drivers/net/mv643xx_eth.c
> @@ -2675,7 +2675,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  	 * Detect hardware parameters.
>  	 */
>  	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> -	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> +	msp->tx_csum_limit = (pd && pd->tx_csum_limit) ?
> +					pd->tx_csum_limit : 9 * 1024;

It's odd using two different check styles for the same
test on consecutive lines.

How about using the same style:

	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
					pd->tx_csum_limit : 9 * 1024;

[patch -next v2] mv643xx_eth: potential null dereference

[Dan Carpenter]

We assume that "pd" can be null on the previous line, and throughout the
function so we should check it here as well.  This was introduced by
9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: style change

diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 73bb8ea..f5e72fe 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2670,7 +2670,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 	 * Detect hardware parameters.
 	 */
 	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
-	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
+	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
+					pd->tx_csum_limit : 9 * 1024;
 	infer_hw_params(msp);
 
 	platform_set_drvdata(pdev, msp);

[patch -next v2] mv643xx_eth: potential null dereference

[Dan Carpenter]

We assume that "pd" can be null on the previous line, and throughout the
function so we should check it here as well.  This was introduced by
9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: style change

diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 73bb8ea..f5e72fe 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2670,7 +2670,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
 	 * Detect hardware parameters.
 	 */
 	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
-	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
+	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
+					pd->tx_csum_limit : 9 * 1024;
 	infer_hw_params(msp);
 
 	platform_set_drvdata(pdev, msp);

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Fri, Jul 23, 2010 at 01:05:05PM +0200, Dan Carpenter wrote:

> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Fri, Jul 23, 2010 at 01:05:05PM +0200, Dan Carpenter wrote:

> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Dan Carpenter schrieb:
> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> v2: style change
> 
> diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
> index 73bb8ea..f5e72fe 100644
> --- a/drivers/net/mv643xx_eth.c
> +++ b/drivers/net/mv643xx_eth.c
> @@ -2670,7 +2670,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  	 * Detect hardware parameters.
>  	 */
>  	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> -	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> +	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
> +					pd->tx_csum_limit : 9 * 1024;
>  	infer_hw_params(msp);
>  
>  	platform_set_drvdata(pdev, msp);

this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
with this version:

    if (!pd ) {
       msp->t_clk = 133000000;
       msp->tx_csum_limit = 9 * 1024;
     }
     else
      {
	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
        msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
       }


re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Dan Carpenter schrieb:
> We assume that "pd" can be null on the previous line, and throughout the
> function so we should check it here as well.  This was introduced by
> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> v2: style change
> 
> diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
> index 73bb8ea..f5e72fe 100644
> --- a/drivers/net/mv643xx_eth.c
> +++ b/drivers/net/mv643xx_eth.c
> @@ -2670,7 +2670,8 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
>  	 * Detect hardware parameters.
>  	 */
>  	msp->t_clk = (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> -	msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> +	msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
> +					pd->tx_csum_limit : 9 * 1024;
>  	infer_hw_params(msp);
>  
>  	platform_set_drvdata(pdev, msp);

this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
with this version:

    if (!pd ) {
       msp->t_clk = 133000000;
       msp->tx_csum_limit = 9 * 1024;
     }
     else
      {
	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
        msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
       }


re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[David Miller]

From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Fri, 23 Jul 2010 13:18:18 +0200

> On Fri, Jul 23, 2010 at 01:05:05PM +0200, Dan Carpenter wrote:
> 
>> We assume that "pd" can be null on the previous line, and throughout the
>> function so we should check it here as well.  This was introduced by
>> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
>> 
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>

Applied.

Re: [patch -next v2] mv643xx_eth: potential null dereference

[David Miller]

From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Fri, 23 Jul 2010 13:18:18 +0200

> On Fri, Jul 23, 2010 at 01:05:05PM +0200, Dan Carpenter wrote:
> 
>> We assume that "pd" can be null on the previous line, and throughout the
>> function so we should check it here as well.  This was introduced by
>> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
>> 
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
> 
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>

Applied.

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Dan Carpenter]

On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
> with this version:
> 
>     if (!pd ) {
>        msp->t_clk = 133000000;
>        msp->tx_csum_limit = 9 * 1024;
>      }
>      else
>       {
> 	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>         msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>        }
> 

But then instead of 2 magic numbers we would have 4. :/

regards,
dan carpenter

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Dan Carpenter]

On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
> with this version:
> 
>     if (!pd ) {
>        msp->t_clk = 133000000;
>        msp->tx_csum_limit = 9 * 1024;
>      }
>      else
>       {
> 	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>         msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>        }
> 

But then instead of 2 magic numbers we would have 4. :/

regards,
dan carpenter

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Dan Carpenter schrieb:
> On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
>> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
>> with this version:
>>
>>     if (!pd ) {
>>        msp->t_clk = 133000000;
>>        msp->tx_csum_limit = 9 * 1024;
>>      }
>>      else
>>       {
>> 	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>>         msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>>        }
>>
> 
> But then instead of 2 magic numbers we would have 4. :/
> 

Yes it can be shorten,

msp->t_clk = 133000000;
msp->tx_csum_limit = 9 * 1024;
if (pd) {
	if (pd->t_clk) msp->t_clk = pd->t_clk ;
	if (pd->tx_csum_limit) sp->tx_csum_limit = pd->tx_csum_limit;
}
pd->t_clk
i was thinking about that in my first posting but i have the feeling that ppl
tend to overlook the "if (pd)" but in this case it is important since the
behavier is different.

IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit have usefull
values than adding a check but this is up to the maintainer.

re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Dan Carpenter schrieb:
> On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
>> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
>> with this version:
>>
>>     if (!pd ) {
>>        msp->t_clk = 133000000;
>>        msp->tx_csum_limit = 9 * 1024;
>>      }
>>      else
>>       {
>> 	msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>>         msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>>        }
>>
> 
> But then instead of 2 magic numbers we would have 4. :/
> 

Yes it can be shorten,

msp->t_clk = 133000000;
msp->tx_csum_limit = 9 * 1024;
if (pd) {
	if (pd->t_clk) msp->t_clk = pd->t_clk ;
	if (pd->tx_csum_limit) sp->tx_csum_limit = pd->tx_csum_limit;
}
pd->t_clk
i was thinking about that in my first posting but i have the feeling that ppl
tend to overlook the "if (pd)" but in this case it is important since the
behavier is different.

IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit have usefull
values than adding a check but this is up to the maintainer.

re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:

> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> have usefull values than adding a check but this is up to the maintainer.

I don't see the point of that at all.  We check against zero to see
whether the caller bothered to fill in the field at all, but if the
caller wants to pass in bogus values, that's up to the caller.

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:

> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> have usefull values than adding a check but this is up to the maintainer.

I don't see the point of that at all.  We check against zero to see
whether the caller bothered to fill in the field at all, but if the
caller wants to pass in bogus values, that's up to the caller.

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Lennert Buytenhek schrieb:
> On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
> 
>> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
>> have usefull values than adding a check but this is up to the maintainer.
> 
> I don't see the point of that at all.  We check against zero to see
> whether the caller bothered to fill in the field at all, but if the
> caller wants to pass in bogus values, that's up to the caller.
> 
at first i have to admit i looked only at the patch.
for me the situation looks this way:

You check the values for 0 (and uses default) or take what ever in pd is.
The current code is setup like:

  1. check if pd is set
  2. check if pd->value is non zero and use it

the whole "check X" can be avoided if you could create a pd with all values
set to default and just take what comes from the user.

my objection agains this kind of code is that it is not obvious
what some one is trying to archive
(pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;

the pd check means: do i have a configuration  ?
the pd->t_clk != 0 means: should i use then or default ?

This is mixing two very different questions. therefore my idea in the last
posting to have a default init if (!pd) and then use the else to make clear
that additional checks for pd->value are expected.

this this is the init code readability and simplicity should be king.

hope that helps,
re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[walter harms]

Lennert Buytenhek schrieb:
> On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
> 
>> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
>> have usefull values than adding a check but this is up to the maintainer.
> 
> I don't see the point of that at all.  We check against zero to see
> whether the caller bothered to fill in the field at all, but if the
> caller wants to pass in bogus values, that's up to the caller.
> 
at first i have to admit i looked only at the patch.
for me the situation looks this way:

You check the values for 0 (and uses default) or take what ever in pd is.
The current code is setup like:

  1. check if pd is set
  2. check if pd->value is non zero and use it

the whole "check X" can be avoided if you could create a pd with all values
set to default and just take what comes from the user.

my objection agains this kind of code is that it is not obvious
what some one is trying to archive
(pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;

the pd check means: do i have a configuration  ?
the pd->t_clk != 0 means: should i use then or default ?

This is mixing two very different questions. therefore my idea in the last
posting to have a default init if (!pd) and then use the else to make clear
that additional checks for pd->value are expected.

this this is the init code readability and simplicity should be king.

hope that helps,
re,
 wh

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Sun, Jul 25, 2010 at 04:47:17PM +0200, walter harms wrote:

> >> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> >> have usefull values than adding a check but this is up to the maintainer.
> > 
> > I don't see the point of that at all.  We check against zero to see
> > whether the caller bothered to fill in the field at all, but if the
> > caller wants to pass in bogus values, that's up to the caller.
> 
> at first i have to admit i looked only at the patch.
> for me the situation looks this way:
> 
> You check the values for 0 (and uses default) or take what ever in pd is.
> The current code is setup like:
> 
>   1. check if pd is set
>   2. check if pd->value is non zero and use it
> 
> the whole "check X" can be avoided if you could create a pd with all values
> set to default and just take what comes from the user.

Why would you want to avoid "check X"?


> my objection agains this kind of code is that it is not obvious
> what some one is trying to archive
> (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> 
> the pd check means: do i have a configuration  ?

Yep.


> the pd->t_clk != 0 means: should i use then or default ?

Yep.


> This is mixing two very different questions.

And?

You're arguing against the use of 'if (a && b)' in general?


> therefore my idea in the last posting to have a default init if (!pd)
> and then use the else to make clear that additional checks for
> pd->value are expected.

Again, I don't see the point of this, and I think we're just splitting
hairs here and wasting everyone's time.


> this this is the init code readability and simplicity should be king.

'if (foo != NULL && foo->value <op> <value>)' is a fairly common C
construct, in my opinion, and I don't see how expanding it into a
multi-line nested if construct will make it either more readable or
simpler.


> hope that helps,

Not really.


thanks,
Lennert

Re: [patch -next v2] mv643xx_eth: potential null dereference

[Lennert Buytenhek]

On Sun, Jul 25, 2010 at 04:47:17PM +0200, walter harms wrote:

> >> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> >> have usefull values than adding a check but this is up to the maintainer.
> > 
> > I don't see the point of that at all.  We check against zero to see
> > whether the caller bothered to fill in the field at all, but if the
> > caller wants to pass in bogus values, that's up to the caller.
> 
> at first i have to admit i looked only at the patch.
> for me the situation looks this way:
> 
> You check the values for 0 (and uses default) or take what ever in pd is.
> The current code is setup like:
> 
>   1. check if pd is set
>   2. check if pd->value is non zero and use it
> 
> the whole "check X" can be avoided if you could create a pd with all values
> set to default and just take what comes from the user.

Why would you want to avoid "check X"?


> my objection agains this kind of code is that it is not obvious
> what some one is trying to archive
> (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
> 
> the pd check means: do i have a configuration  ?

Yep.


> the pd->t_clk != 0 means: should i use then or default ?

Yep.


> This is mixing two very different questions.

And?

You're arguing against the use of 'if (a && b)' in general?


> therefore my idea in the last posting to have a default init if (!pd)
> and then use the else to make clear that additional checks for
> pd->value are expected.

Again, I don't see the point of this, and I think we're just splitting
hairs here and wasting everyone's time.


> this this is the init code readability and simplicity should be king.

'if (foo != NULL && foo->value <op> <value>)' is a fairly common C
construct, in my opinion, and I don't see how expanding it into a
multi-line nested if construct will make it either more readable or
simpler.


> hope that helps,

Not really.


thanks,
Lennert