[Patch] net/xfrm/xfrm_policy.c: Some small improvements

[Patch] net/xfrm/xfrm_policy.c: Some small improvements

[WANG Cong]

This patch contains the following changes.

	- Use 'bool' instead of 'int' for booleans.
	- Use 'size_t' instead of 'int' for 'sizeof' return value.
	- Some style fixes.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

---
 net/xfrm/xfrm_policy.c |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 5d6a81d..311b08f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -476,17 +476,17 @@ static u32 xfrm_gen_index(u8 type, int dir)
 		struct hlist_head *list;
 		struct xfrm_policy *p;
 		u32 idx;
-		int found;
+		bool found;
 
 		idx = (idx_generator | dir);
 		idx_generator += 8;
 		if (idx == 0)
 			idx = 8;
 		list = xfrm_policy_byidx + idx_hash(idx);
-		found = 0;
+		found = false;
 		hlist_for_each_entry(p, entry, list, byidx) {
 			if (p->index == idx) {
-				found = 1;
+				found = true;
 				break;
 			}
 		}
@@ -499,8 +499,8 @@ static inline int selector_cmp(struct xfrm_selector *s1, struct xfrm_selector *s
 {
 	u32 *p1 = (u32 *) s1;
 	u32 *p2 = (u32 *) s2;
-	int len = sizeof(struct xfrm_selector) / sizeof(u32);
-	int i;
+	size_t len = sizeof(struct xfrm_selector) / sizeof(u32);
+	size_t i;
 
 	for (i = 0; i < len; i++) {
 		if (p1[i] != p2[i])
@@ -953,7 +953,7 @@ static int xfrm_policy_lookup(struct flowi *fl, u16 family, u8 dir,
 #ifdef CONFIG_XFRM_SUB_POLICY
 end:
 #endif
-	if ((*objp = (void *) pol) != NULL)
+	if ((*objp = pol) != NULL)
 		*obj_refp = &pol->refcnt;
 	return err;
 }
@@ -1137,7 +1137,7 @@ xfrm_tmpl_resolve_one(struct xfrm_policy *policy, struct flowi *fl,
 	xfrm_address_t *saddr = xfrm_flowi_saddr(fl, family);
 	xfrm_address_t tmp;
 
-	for (nx=0, i = 0; i < policy->xfrm_nr; i++) {
+	for (nx = 0, i = 0; i < policy->xfrm_nr; i++) {
 		struct xfrm_state *x;
 		xfrm_address_t *remote = daddr;
 		xfrm_address_t *local  = saddr;
@@ -1395,7 +1395,7 @@ free_dst:
 }
 
 static int inline
-xfrm_dst_alloc_copy(void **target, void *src, int size)
+xfrm_dst_alloc_copy(void **target, void *src, size_t size)
 {
 	if (!*target) {
 		*target = kmalloc(size, GFP_ATOMIC);
@@ -1554,7 +1554,7 @@ restart:
 #endif
 		nx = xfrm_tmpl_resolve(pols, npols, fl, xfrm, family);
 
-		if (unlikely(nx<0)) {
+		if (unlikely(nx < 0)) {
 			err = nx;
 			if (err == -EAGAIN && sysctl_xfrm_larval_drop) {
 				/* EREMOTE tells the caller to generate
@@ -1688,7 +1688,8 @@ xfrm_state_ok(struct xfrm_tmpl *tmpl, struct xfrm_state *x,
 	      unsigned short family)
 {
 	if (xfrm_state_kern(x))
-		return tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, tmpl->encap_family);
+		return tmpl->optional &&
+			!xfrm_state_addr_cmp(tmpl, x, tmpl->encap_family);
 	return	x->id.proto == tmpl->id.proto &&
 		(x->id.spi == tmpl->id.spi || !tmpl->id.spi) &&
 		(x->props.reqid == tmpl->reqid || !tmpl->reqid) &&
@@ -1777,7 +1778,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
 	if (skb->sp) {
 		int i;
 
-		for (i=skb->sp->len-1; i>=0; i--) {
+		for (i = skb->sp->len-1; i >= 0; i--) {
 			struct xfrm_state *x = skb->sp->xvec[i];
 			if (!xfrm_selector_match(&x->sel, &fl, family))
 				return 0;

Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements

[David Miller]

From: WANG Cong <xiyou.wangcong@gmail.com>
Date: Thu, 6 Dec 2007 19:01:23 +0800

> 
> This patch contains the following changes.
> 
> 	- Use 'bool' instead of 'int' for booleans.
> 	- Use 'size_t' instead of 'int' for 'sizeof' return value.
> 	- Some style fixes.
> 
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

Normally I would let a patch like this sit in my mailbox
for a week and then delete it.

But this time I'll just let you know up front that I
don't see much value in this patch.  It is not a clear
improvement to replace int's with bool's in my mind and
the other changes are just whitespace changes.

And thus I can delete the patch from my mailbox
immediately :-)

Sorry.

Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements

[Richard Knutsson]

David Miller wrote:
> From: WANG Cong <xiyou.wangcong@gmail.com>
> Date: Thu, 6 Dec 2007 19:01:23 +0800
>
>   
>> This patch contains the following changes.
>>
>> 	- Use 'bool' instead of 'int' for booleans.
>> 	- Use 'size_t' instead of 'int' for 'sizeof' return value.
>> 	- Some style fixes.
>>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: David Miller <davem@davemloft.net>
>> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
>>     
>
> Normally I would let a patch like this sit in my mailbox
> for a week and then delete it.
>   
That is evil! ;)
> But this time I'll just let you know up front that I
> don't see much value in this patch.  It is not a clear
> improvement to replace int's with bool's in my mind and
> the other changes are just whitespace changes.
>   
Is it not an improvement to distinct booleans from actual values? Do you 
use integers for ASCII characters too? It can also avoid some potential 
bugs like the 'if (i == TRUE)'...
What is wrong with 'size_t' (since it is unsigned, compared to (some) 
'int')?

/Richard Knutsson

Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements

[Herbert Xu]

On Thu, Dec 06, 2007 at 03:37:46PM +0100, Richard Knutsson wrote:
>
> Is it not an improvement to distinct booleans from actual values? Do you 
> use integers for ASCII characters too? It can also avoid some potential 
> bugs like the 'if (i == TRUE)'...
> What is wrong with 'size_t' (since it is unsigned, compared to (some) 
> 'int')?

I agree with Dave.  There are so many useful things that we can do
(and need to do) in IPsec that bool/size_t conversions just add
churn without adding much value.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements

[David Miller]

From: Richard Knutsson <ricknu-0@student.ltu.se>
Date: Thu, 06 Dec 2007 15:37:46 +0100

> David Miller wrote:
> > But this time I'll just let you know up front that I
> > don't see much value in this patch.  It is not a clear
> > improvement to replace int's with bool's in my mind and
> > the other changes are just whitespace changes.
> >   
> Is it not an improvement to distinct booleans from actual values? Do you 
> use integers for ASCII characters too? It can also avoid some potential 
> bugs like the 'if (i == TRUE)'...
> What is wrong with 'size_t' (since it is unsigned, compared to (some) 
> 'int')?

When you say "int found;" is there any doubt in your mind that
this integer is going to hold a 1 or a 0 depending upon whether
we "found" something?

That's the problem I have with these kinds of patches, they do
not increase clarity, it's just pure mindless edits.

In new code, fine, use booleans if you want.

I would even accept that it helps to change to boolean for
arguments to functions that are global in scope.

But not for function local variables in cases like this.

Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements

[Richard Knutsson]

David Miller wrote:
> From: Richard Knutsson <ricknu-0@student.ltu.se>
> Date: Thu, 06 Dec 2007 15:37:46 +0100
>
>   
>> David Miller wrote:
>>     
>>> But this time I'll just let you know up front that I
>>> don't see much value in this patch.  It is not a clear
>>> improvement to replace int's with bool's in my mind and
>>> the other changes are just whitespace changes.
>>>   
>>>       
>> Is it not an improvement to distinct booleans from actual values? Do you 
>> use integers for ASCII characters too? It can also avoid some potential 
>> bugs like the 'if (i == TRUE)'...
>> What is wrong with 'size_t' (since it is unsigned, compared to (some) 
>> 'int')?
>>     
>
> When you say "int found;" is there any doubt in your mind that
> this integer is going to hold a 1 or a 0 depending upon whether
> we "found" something?
>
> That's the problem I have with these kinds of patches, they do
> not increase clarity, it's just pure mindless edits.
>   
But is there not a good thing if also the compiler knows + names are 
sometime not as clear as that one?
> In new code, fine, use booleans if you want.
>
> I would even accept that it helps to change to boolean for
> arguments to functions that are global in scope.
>
> But not for function local variables in cases like this.
>   
Oh, I see your point now. Believed it to be yet another 'booleans is not 
C idiom'.

Sorry about the noise
Richard Knutsson