[Bro-Dev] Alignment check in RPC code

Vern Paxson vern at icir.org
Fri Dec 10 19:28:15 PST 2010


> However, on my Mac OS, buf it not 4-byte aligned. If this is the case
> than the 32-bit value is byte-swapped (which is a bug, which makes the
> testsuite fail on MAC OS X, which is why I discovered this code).

Weird, as I run the testsuite pretty much exclusively under MacOS X.
Perhaps there's something different in our environments such that it's
aligned in mine but not in yours.

> Mac OS X is fine with doing un-aligned reads. More general, with current
> architectures and OSes, does one still need to check for 4- or 8-byte
> alignments?

I don't think it's prudent to throw out this check.  There's a difference
between "predominant" architectures and OSes vs. "current".  Your statement
is really about the former, and will potentially limit portability (in a
nasty way, i.e., a crash on a maybe-not-commonly-executed code path).

> If so, should this be done higher up in the Analyzer tree?
> But my thought is that we can just remove the alignment check here.

I think significantly better is to use:

	uint32 bits32 = XDR_aligned(buf) ? ntohl(*(uint32*) buf) :
		((buf[0] << 24) | (buf[1] << 16) | (buf[2] << 8) | buf[3]);

and remove the later call to ntohl().

		Vern


More information about the bro-dev mailing list