NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: David Holland <>
Subject: Re: kern/43541: Unaligned access in pf_normalize_tcpopt()
Date: Mon, 5 Jul 2010 21:07:27 +0000

 On Mon, Jul 05, 2010 at 08:20:03PM +0000, David Laight wrote:
  >>>  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.
 Well, I've also *seen* compilers store temporary values to scratch
 slots in the stack and immediately read them back. The question is
 whether a reasonably sane and modernish compiler that's been at least
 somewhat debugged is going to do anything so silly.
 However, it's also moot because such micro-optimizations are not worth
 spending time thinking about.
  >>>  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 ...
 Hrm, perhaps, I guess proving that optp[2] and r->max_rss don't
 overlap would require global analysis.
 David A. Holland

Home | Main Index | Thread Index | Old Index