[Xorp-hackers] Alignment problem in xrl_args.cc on xScale

[Pavlin Radoslavov]

Bruce M Simpson <bms at incunabulum.net> 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
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers