Re: kern/43541: Unaligned access in pf_normalize_tcpopt()

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR kern/43541; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/43541: Unaligned access in pf_normalize_tcpopt()
Date: Mon, 5 Jul 2010 21:22:46 +0100

 On Tue, Jun 29, 2010 at 11:40:05PM +0000, David Holland wrote:
 > 
 >  On Tue, Jun 29, 2010 at 11:20:05PM +0000, David Laight wrote:
 >   >>> +                              optp[2] = (u_char)(r->max_mss >> 8) & 
 > 0xff;
 >   >>> +                              optp[3] = (u_char)(r->max_mss) & 0xff;
 >   >>  
 >   >>  Do those casts serve any purpose?
 >   >  
 >   >  Do the '& 0xff' serve any purpose ?
 >  
 >  Arguably not, but they at least can't mask other bugs.
 >  
 >   >  The compiler may well generate code that 'and's the value with 0xff 
 > twice
 >   >  before storing the low 8 bits away!
 >  
 >  Not very likely, except perhaps with gcc -O0, which is so stupid
 >  anyway that there's no point worrying about it.
 
 Not in my experience!
 I've certainly seen compilers mask with 0xff then save the low bits.
 
 >   >  OTOH reversing the two lines may well save a temporary register.
 >   >  Hmmm... actually you want to cache r->max_rss in a local, the compiler
 >   >  is most likely required to re-read r->max_rss between the two 
 > statements.
 >  
 >  Why would it be? It's not IIRC marked volatile.
 
 The aliasing rules ...
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost