Is chap9/c_inclusion.c violating the strict aliasing rule?

[yeah-boi]

I could be wrong, but it looks like chap9/c_inclusion.c violates the strict aliasing rule.

[sayon]

Here is the listing itself for the reference:

#include <stdio.h>

struct parent {
    const char* field_parent;
};

struct child { 
    struct parent base;
    const char* field_child;
};

void parent_print( struct parent* this ) {
    printf( "%s\n", this->field_parent ); 
}

int main( int argc, char** argv ) {
    struct child c;
    c.base.field_parent = "parent";
    c.field_child = "child";
    parent_print( (struct parent*) &c );

    return 0;
}

I do think that this is a very good observation, because the usual list of aliasing rules does not discuss this case.

I think however that it does not violate the strict aliasing rules because it is a well-defined behavior (c11 draft, section 6.7.2.1 page 115):

15 
[...] A pointer to a structure object, suitably converted, points to its initial member [...] and vice versa.

As we are converting the pointer at the call site, it should work fine:

(struct parent*) &c

Omitting the cast issues a warning, because by default these types are not marked as compatible.

In C++, the similar thing happens when using reinterpret_cast.

[yeah-boi]

Yes, you are correct. This issue can be closed. As you say there is a struct parent object at that memory address, so no problem since we use that same type when accessing it.

Using offsetof we could even do something similar with other fields of a struct (second, third, ...) without violating strict aliasing.