Safe, efficient way to access unaligned data in a network packet from C

Question

I'm writing a program in C for Linux on an ARM9 processor. The program is to access network packets which include a sequence of tagged data like:

<fieldID><length><data><fieldID><length><data> ...

The fieldID and length fields are both uint16_t. The data can be 1 or more bytes (up to 64k if the full length was used, but it's not).

As long as <data> has an even number of bytes, I don't see a problem. But if I have a 1- or 3- or 5-byte <data> section then the next 16-bit fieldID ends up not on a 16-bit boundary and I anticipate alignment issues. It's been a while since I've done any thing like this from scratch so I'm a little unsure of the details. Any feedback welcome. Thanks.

Answer 1

To avoid alignment issues in this case, access all data as an unsigned char *. So:

unsigned char *p;
//...
uint16_t id = p[0] | (p[1] << 8);
p += 2;

The above example assumes "little endian" data layout, where the least significant byte comes first in a multi-byte number.

Answer 2

You should have functions (inline and/or templated if the language you're using supports those features) that will read the potentially unaligned data and return the data type you're interested in. Something like:

uint16_t unaligned_uint16( void* p)
{
    // this assumes big-endian values in data stream
    //  (which is common, but not universal in network
    //  communications) - this may or may not be 
    //  appropriate in your case

    unsigned char* pByte = (unsigned char*) p;

    uint16_t val = (pByte[0] << 8) | pByte[1];

    return val;
}

Answer 3

The easy way is to manually rebuild the uint16_ts, at the expense of speed:

uint8_t *packet = ...;
uint16_t fieldID = (packet[0] << 8) | packet[1];  // assumes big-endian host order
uint16_t length = (packet[2] << 8) | packet[2];
uint8_t *data = packet + 4;
packet += 4 + length;

If your processor supports it, you can type-pun or use a union (but beware of strict aliasing).

uint16_t fieldID = htons(*(uint16_t *)packet);
uint16_t length = htons(*(uint16_t *)(packet + 2));

Note that unaligned access aren't always supported (e.g. they might generate a fault of some sort), and on other architectures, they're supported, but there's a performance penalty.

If the packet isn't aligned, you could always copy it into a static buffer and then read it:

static char static_buffer[65540];
memcpy(static_buffer, packet, packet_size);  // make sure packet_size <= 65540
uint16_t fieldId = htons(*(uint16_t *)static_buffer);
uint16_t length = htons(*(uint16_t *)(static_buffer + 2));

Personally, I'd just go for option #1, since it'll be the most portable.

Answer 4

Alignment is always going to be fine, although perhaps not super-efficient, if you go through a byte pointer.

Setting aside issues of endian-ness, you can memcpy from the 'real' byte pointer into whatever you want/need that is properly aligned and you will be fine.

(this works because the generated code will load/store the data as bytes, which is alignment safe. It's when the generated assembly has instructions loading and storing 16/32/64 bits of memory in a mis-aligned manner that it all falls apart).