> Thanks for the clarification. As a programmer I'm inclined not to rely on any > OS-specific promises about structure alignment of external data -- I try to > make code more portable than that -- but I can see how there's a slight > performance gain, and how this is an issue for someone who wants to take > advantage of that. And after all, if that's what the docs claim, it probably > ought to behave that way, hmm?
In a number of places, tcpdump *doesn't* assume alignment. On platforms that require strict alignment (platforms where LBL_ALIGN is defined), "ip_print()" checks whether the IP header is properly aligned and, if not, copies the entire packet to a mallocated (and thus aligned) buffer and works on that. "ip6_print()" and "atalk_print()" do the same. Some link-layer dissectors have headers that consist only of byte and byte-array fields (Ethernet, FDDI); others have properly-aligned multi-byte integral fields (Token Ring). We should perhaps check the others. At least some other protocols running atop the link layer use the EXTRACT_ macros, although "isoclns_print()" just casts the raw data pointer to a structure pointer - even if the fields in the structure are all byte or byte-array fields, I think Alpha compilers may assume proper alignment and generate aligned loads and extracts for doing 1-byte or 2-byte loads (I think we saw that here at NetApp), at least when not generating code for Alpha processors with BWX instructions. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
