Bruce M Simpson <[EMAIL PROTECTED]> wrote: > There are only 2 other places where the alignment warning is triggered. > > 1. in packet.cc ArpHeader::assign(). > > uint8_t* is being cast to ArpHeader*, whose first member is uint16_t and > thus triggers the alignment warning. > > This code seems to be dubious where strict alignment is concerned.
Even without the alignment issue, such casting is questionable (to say the least) and very anti-C++. > 2. in vrrp_packet.cc VrrpHeader::assign(). > > In this case, the first member is a C-style bit-field contained in a > uint8_t. > > Normally I wouldn't expect this to generate an error, it is possible > that the compiler is attempting to use ARM bit-field opcodes, although I > was under the impression these were only part of Thumb-2. > > In both cases, we are casting an arbitrary uint8_t* pointer to a > structure type. The two alignment warnings in the XRL layer are easily > fixed by using extract_32(). However these further warnings refer to > aggregate types so we can't deal with them so easily. I agree with you. Potential issues like this are some of the reasons that the backend implementation of IpHeader4/IpHeader4Writer (and the corresponding IPv6 version) in libproto/packet.hh is done the way it is. If fixing the issue is not going to be trivial, please submit a Bugzilla entry. Thanks, Pavlin > I'm sure I saw issues like this with the STCP packet header in libxipc. > > regards > BMS > > _______________________________________________ > Xorp-hackers mailing list > [email protected] > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
