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.

Reply via email to