netdev - Re: [PATCH 2/4] tcpv6: trivial formatting changes to send

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0810091254160.1034@wrl-59.cs.helsinki.fi>
Date:	Thu, 9 Oct 2008 12:58:07 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"YOSHIFUJI Hideaki / 吉藤英明" 
	<yoshfuji@...ux-ipv6.org>
cc:	David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/4] tcpv6: trivial formatting changes to send_(ack|reset)

On Thu, 9 Oct 2008, YOSHIFUJI Hideaki / ???? wrote:

> In article <1223544937-12595-2-git-send-email-ilpo.jarvinen@...sinki.fi> (at Thu,  9 Oct 2008 12:35:35 +0300), "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> says:
> 
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
> > ---
> >  net/ipv6/tcp_ipv6.c |    7 +++----
> >  1 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> > index 2084f5a..3f268a3 100644
> > --- a/net/ipv6/tcp_ipv6.c
> > +++ b/net/ipv6/tcp_ipv6.c
> > @@ -948,7 +948,7 @@ static void tcp_v6_send_reset(struct sock *sk, struct sk_buff *skb)
> >  	struct flowi fl;
> >  	struct net *net = dev_net(skb->dst->dev);
> >  	struct sock *ctl_sk = net->ipv6.tcp_sk;
> > -	unsigned int tot_len = sizeof(*th);
> > +	unsigned int tot_len = sizeof(struct tcphdr);
> >  #ifdef CONFIG_TCP_MD5SIG
> >  	struct tcp_md5sig_key *key;
> >  #endif
> 
> I usually prefer sizeof(var) (or sizeof(*ptr)) over sizeof(type).
> Could you justify this change?

My point was to make those two functions as equal as possible before merge 
so that it's more easier to track what happens at the merge, both 
versions pre-existed anyway. Sure I don't have much opinion either way.

-- 
 i.