How do I interpret a message payload without violating type aliasing rules?

Question

My program receives messages over the network. These messages are deserialized by some middleware (i.e. someone else's code which I cannot change). My program receives objects that look something like this:

struct Message {
    int msg_type;
    std::vector<uint8_t> payload;
};

By examining msg_type I can determine that the message payload is actually, for example, an array of uint16_t values. I would like to read that array without an unnecessary copy.

My first thought was to do this:

const uint16_t* a = reinterpret_cast<uint16_t*>(msg.payload.data());

But then reading from a would appear to violate the standard. Here is clause 3.10.10:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

• the dynamic type of the object,
• a cv-qualified version of the dynamic type of the object,
• a type similar (as defined in 4.4) to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to the dynamic type of the object,
• a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
• an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union),
• a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
• a char or unsigned char type.

In this case, a would be the glvalue and uint16_t* does not appear to meet any of the listed criteria.

So how do I treat the payload as an array of uint16_t values without invoking undefined behavior or performing an unnecessary copy?

Answer 1

If you are going to consume the values one by one then you can memcpy to a uint16_t, or write payload[0] + 0x100 * payload[1] etc. , as to which behaviour you want. This will not be "inefficient".

If you have to call a function that only takes an array of uint16_t, and you cannot change the struct that delivers Message, then you are out of luck. In Standard C++ you'll have to make the copy.

If you are using gcc or clang, another option is to set -fno-strict-aliasing while compiling the code in question.

Answer 2

If you want strictly to follow C++ Standard without UB, and not employ non-standard compiler extensions, you can try:

uint16_t getMessageAt(const Message& msg, size_t i) {
   uint16_t tmp;
   memcpy(&tmp, msg.payload.data() + 2 * i, 2);
   return tmp;
}

Compiler optimizations should avoid memcpy copying here in the generated machine code; see, e.g., Type Punning, Strict Aliasing, and Optimization.

There is, in fact, copying into the return value, but depending on what you will do with it, this copy can be optimized away as well (e.g., this value can be loaded into a register and used only there).

Answer 3

If you want to be strictly correct, as the standard that you quoted says, you can't. If you want behavior to be well defined, you will need to make the copy.

If the code is meant to be portable, you will need to handle endianness either way, and reconstruct your uint16_t values from individual uint8_t bytes, and this by definition requires a copy.

If you really know what you're doing, you can ignore the standard, and just do the reinterpret_cast that you described.

GCC and clang support -fno-strict-aliasing to prevent the optimization generating broken code. As far as I'm aware, at the time of this writing the Visual Studio compiler does not have a flag, and never performs this kind of optimizations - unless you use declspec(restrict) or __restrict.

Answer 4

Your code may not be UB (or border line depending on reader sensibility) if for example the vector data had been built this way:

Message make_array_message(uint16_t* x, size_t n){
 Message m;
 m.type = types::uint16_t_array;
 m.payload.reserve(sizeof(uint16_t)*n);
 std::copy(x,x+n,reinterpret_cast<uint16_t*>(m.payload.data()));
 return m;
 }

In this code the vector's data hold a sequence of uint16_t even if it is declared as uint8_t. So accessing the data using this pointer:

const uint16_t* a = reinterpret_cast<uint16_t*>(msg.payload.data());

Is perfectly fine. But accessing the vector's data as a uint8_t would be UB. Accessing a[1] would work on all compilers, but it is UB in the current standard. This is arguably a defect in the standard, and the c++ standardization committee is working to fix it, see P0593 Implicit object creation for low level object manipulation.

As of now, in my own code, I do not deal with defects in the standard, I prefer to follow compiler behavior because for this subject, this is coder and compiler that make rules and the standard will just follow!