Talk:c/language/object

You say:

Given an object with effective type T1, using an lvalue expression (typically, dereferencing a pointer) of a different type T2 is undefined behavior, unless:

...

• T2 is an aggregate type (...) that includes one of the aforementioned types among its members

Really? So, am I to believe that this is not UB?

struct I_contain_an_int_among_my_members {
    char blah;
    double yadda;
    int finally_int;
};
 
int main()
{
    int our_T1 = 5;
    struct I_contain_an_int_among_my_members *our_T2 =
        (struct I_contain_an_int_among_my_members*)(&our_T1);
    // If it's valid to refer to T1 through T2*... Let's go wild:
    printf("%f\n", our_T2->yadda);

Ah, and I also heard that "In C structs, a Base* can point to a Derived if Base is the first member in Derived". If it's correct, perhaps it would be worthy of mentioning?

http://stackoverflow.com/questions/7312555/in-c-does-a-pointer-to-a-structure-always-point-to-its-first-member

The point of the aliasing rule is, ultimately, to permit an optimization. It's saying that in a function that receives a pointer to int and a pointer to I_contain_an_int_among_my_members, the compiler must re-read the value pointed to by the pointer to int after writing a struct through the pointer to I_contain_an_int_among_my_members. Good point that it's unclear here since we just copied the standardese instead of explaining what it means, let's see if we can expand. As for the rule that there is no padding before the first element, it is mentioned in c/language/struct--Cubbi (talk) 04:40, 20 May 2017 (PDT)

Effective types in pre-C99

The item "effective type" was originally added in C99 via WG14 N640.

I found that C89 had already said that storage allocated by allocation functions can be accessed through any suitable sized object type including array. However, the response in DR028 said that strict aliasing rules apply to dynamically allocated objects, without specifying their effective type.

In my opinion, DR028 cannot be applied to C89 properly without specifying effective types, so the item "effective type" should be treated as a DR applied to C89. But the specification that memcpy and memmove (alongwith "or is copied as an array of character type" in C standard but missed in the page) preserve effective types looks like a new feature.

Shall we mark any part in "Effective type" with since C99?

--Fruderica (talk) 21:47, 19 May 2020 (PDT)

I suppose you could revbox and add a C89 box saying what C89 said, though it would really be just a historic curiosity at this point - the reality has always been that objects can be implicitly created by malloc, however it's specified --Cubbi (talk) 09:23, 20 May 2020 (PDT)