From: walter harms <wharms@bfs.de>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Dan Carpenter <error27@gmail.com>, Joe Perches <joe@perches.com>,
"David S. Miller" <davem@davemloft.net>,
Jiri Pirko <jpirko@redhat.com>,
Denis Kirjanov <kirjanov@gmail.com>,
Saeed Bishara <saeed@marvell.com>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch -next v2] mv643xx_eth: potential null dereference
Date: Sun, 25 Jul 2010 16:47:17 +0200 [thread overview]
Message-ID: <4C4C4E75.4080603@bfs.de> (raw)
In-Reply-To: <20100724190036.GA21121@mail.wantstofly.org>
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
next prev parent reply other threads:[~2010-07-25 14:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-23 10:15 [patch -next] mv643xx_eth: potential null dereference Dan Carpenter
2010-07-23 10:32 ` Joe Perches
2010-07-23 11:05 ` [patch -next v2] " Dan Carpenter
2010-07-23 11:18 ` Lennert Buytenhek
2010-07-23 20:05 ` David Miller
2010-07-23 16:30 ` walter harms
2010-07-23 22:15 ` Dan Carpenter
2010-07-24 8:59 ` walter harms
2010-07-24 19:00 ` Lennert Buytenhek
2010-07-25 14:47 ` walter harms [this message]
2010-07-25 15:54 ` Lennert Buytenhek
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=4C4C4E75.4080603@bfs.de \
--to=wharms@bfs.de \
--cc=buytenh@wantstofly.org \
--cc=davem@davemloft.net \
--cc=error27@gmail.com \
--cc=joe@perches.com \
--cc=jpirko@redhat.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kirjanov@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=saeed@marvell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).