Does this macro violate the STRICT ALIASING RULE?

Question

I'm fixing some code not written by me, so I found this:

#define get_u_int16_t(X,O)  (*(u_int16_t *)(((u_int8_t *)X) + O))

How can I change it to keep the rule, if it violating it ?

The macro is called in this way:

if(get_u_int16_t(packet->payload, i) == ...) { ... }

where payload is a const unsigned char * and i is an unsigned int .

The situation is:

struct orig {
   [...]
   struct pkt packet;
}*;

struct pkt {
   [...]
   const u_int8_t *payload;
 }*;

Called in this way:

struct orig * flow;
struct pkt * packet = &flow->packet;

payload is a string

i begins with a value of 0 and it is inside a for that loop for the lenght of payload ( u_int16_t len ):

for(i = 0; i < len; i++) {
   if(get_u_int16_t(packet->payload, a) == /*value*/) {
   // do stuff
}

Answer 1

The macro itself doesn't violate the strict aliasing rule; it depends how you use it. If you only use it to read already existing objects of type u_int16_t or a compatible type then it's fine; if on the other hand you use it to read e.g. parts of a 64-bit integer or a floating-point object then that would be a strict aliasing violation, as well as (possibly) an alignment violation.

As always, you can make the code safe using memcpy:

inline u_int16_t read_u_int16_t(const void *p) {
    u_int16_t val;
    memcpy(&val, p, sizeof(val));
    return val;
}
#define get_u_int16_t(X,O)  (read_u_int16_t(((u_int8_t *)X) + O))

As @2501 points out this may be invalid if u_int8_t is not a character type, so you should just use char * for pointer arithmetic:

#define get_u_int16_t(X,O)  (read_u_int16_t(((char *)X) + O))

Answer 2

There are two ways to write code of the type you're interested in:

1. Use pointers of type "unsigned char*" to access anything, assemble values out of multiple bytes, and tolerate the performance hit.

2. If you know that pointer alignment won't be an issue, use a dialect of C that doesn't semantically gut it. GCC can implement such a dialect if invoked with -fno-strict-aliasing, but since gcc has no way to prevent obtuse "optimizations" without blocking useful and sensible optimizations, getting good performance from such a dialect may require learning how to use restrict.

Some people would argue that approach #1 is better, and for many PC-side programming purposes I'd tend to agree. For embedded software, however, I would suggest staying away from gcc's default dialect since there's no guarantee that the things gcc regards as defined behavior today will remain so tomorrow. I'm not sure where the authors of gcc got the notion that the authors of the Standard were trying to specify all of the forms of aliasing that a quality microprocessor implementation should support, rather than establish a minimum baseline for platforms where no forms of type punning other than "unsigned char" would be useful.