Re: [PATCH] Support PROXY protocol

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.
Received on Wed Aug 13 2014 - 19:54:52 MDT