Can Aliasing Problems be Avoided with const Variables

Question

My company uses a messaging server which gets a message into a const char* and then casts it to the message type.

I\'ve become concerned about this afte

Answer 1

So my understanding is that you are doing something like that:

enum MType { J,K };
struct MessageX { MType type; };

struct MessageJ {
    MType type{ J };
    int id{ 5 };
    //some other members
};
const char* popMessage() {
    return reinterpret_cast(new MessageJ());
}
void MessageServer(const char* foo) {
    const MessageX* msgx = reinterpret_cast(foo);
    switch (msgx->type) {
        case J: {
            const MessageJ* msgJ = reinterpret_cast(foo);
            std::cout << msgJ->id << std::endl;
        }
    }
}

int main() {
    const char* foo = popMessage();
    MessageServer(foo);
}

If that is correct, then the expression msgJ->id is ok (as would be any access to foo), as msgJ has the correct dynamic type. msgx->type on the other hand does incur UB, because msgx has a unrelated type. The fact that the the pointer to MessageJ was cast to const char* in between is completely irrelevant.

As was cited by others, here is the relevant part in the standard (the "glvalue" is the result of dereferencing the pointer):

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:52

1. the dynamic type of the object,
2. a cv-qualified version of the dynamic type of the object,
3. a type similar (as defined in 4.4) to the dynamic type of the object,
4. a type that is the signed or unsigned type corresponding to the dynamic type of the object,
5. a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
6. 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),
7. a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
8. a char or unsigned char type.

As far as the discussion "cast to char*" vs "cast from char*" is concerned:
You might know that the standard doesn't talk about strict aliasing as such, it only provides the list above. Strict aliasing is one analysis technique based on that list for compilers to determine which pointers can potentially alias each other. As far as optimizations are concerned, it doesn't make a difference, if a pointer to a MessageJ object was cast to char* or vice versa. The compiler cannot (without further analysis) assume that a char* and MessageX* point to distinct objects and will not perform any optimizations (e.g. reordering) based on that.

Of course that doesn't change the fact that accessing a char array via a pointer to a different type would still be UB in C++ (I assume mostly due to alignment issues) and the compiler might perform other optimizations that could ruin your day.

EDIT:

What I'm asking is: Will the initialization of a const object, by casting from a char*, ever be optimized below where that object is cast to another type of object, such that I am casting from uninitialized data?

No it will not. Aliasing analysis doesn't influence how the pointer itself is handled, but the access through that pointer. The compiler will NOT reorder the write access (store memory address in the pointer variable) with the read access (copy to other variable / load of address in order to access the memory location) to the same variable.