On 08/12/2014 06:18 PM, Alex Rousskov wrote: > On 08/12/2014 10:17 AM, Amos Jeffries wrote: >> On 11/08/2014 4:32 p.m., Alex Rousskov wrote: >>> On 08/05/2014 08:31 PM, Amos Jeffries wrote: >>>> + const char *clen = in.buf.rawContent() + Proxy2p0magic.length() + 2; >>>> + const uint16_t len = ntohs(*(reinterpret_cast<const uint16_t >>>> *>(clen)));
>>> Could this cast violate integer alignment rules on some platforms? If >>> yes, we may have to memcpy those two bytes first. I do not think we can >>> guarantee any specific alignment for in.buf.rawContent() and, hence, we >>> cannot guarantee any specific alignment for clen. >> Unsure. The uint16_t should be compiled as 8-bit aligned AFAIK. In >> theory we only encounter that type of problem with the more complex >> types (like pax below). > Your call, but I would memcpy() before interpreting that clen value to > be on the safe side. It is a very fast copy. If you do not memcpy(), > please add a comment. For example: > > // We hope uint16_t can start at any byte, w/o alignment problems. FWIW, the following page says "uint16_t* requires 2-byte alignment" at least for some ARM processors, but I have not dug deep enough to verify whether their claim is applicable to our code. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Given the above, I am even more pessimistic that we can safely get away with unaligned uint16_t access in all environments. HTH, Alex.
