Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker <uec...@tugraz.at> wrote: > > > > > > > Let me give you an complication example made valid in C++: > > > > struct B { float x; float y; }; > > struct X { int n; char buf[8]; } x, y; > > > > void foo(struct B *b) > > { > > memcpy (x.buf, b, sizeof (struct B)); // in C++: new (x.buf) B (*b); > > Let's make it an explicit store for the moment > (should not make a difference though): > > *(struct B*)x.buf = *b; > > > y = x; // (*) > > } > > > > What's the effective type of 'x' in the 'y = x' copy? > > Good point. The existing wording would take the declared > type of x as the effective type, but this may not be > what you are interested in. Let's assume that x has no declared > type but that it had effective type struct X before the > store to x.buf (because of an even earlier store to > x with type struct X). > > There is a general question how stores to subobjects > affect effective types and I do not think this is clear > even before this proposed change.
Actually, I think this is not allowed because: "An object shall have its stored value accessed only by an lvalue expression that has one of the following types: — a type compatible with the effective type of the object, ... — an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or — a character type." ... and we would need to move "a character type" above in the list to make it defined. Martin