Am Montag, dem 18.03.2024 um 14:21 +0100 schrieb Richard Biener:
> On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker <uec...@tugraz.at> wrote:
> >
> > 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.
>
> So after
>
> *(struct B*)x.buf = *b;
>
> 'x' cannot be used to access itself? In particular also
> an access to 'x.n' is affected by this?
According to the current wording and assuming x has no
a declared type, x.buf would acquire an effective
type of struct B. Then if x.buf is read as part of
a x it is accessed with an lvalue of struct X (which
does not include a struct B but a character buffer).
So yes, currently it would be undefined behavior
and the proposed wording would not change this. Clearly,
we should include an additional change to fix this.
>
> You are right that the current wording of the standard doesn't
> clarify any of this but this kind of storage abstraction is used
> commonly in the embedded world when there's no runtime
> library providing allocation. And you said you want to make
> the standard closer to implementation practice ...
Well, we are working on it... Any help is much appreciated.
>
> Elsewhere when doing 'y = x' people refer to the wording that
> aggregates are copied elementwise but it's not specified how
> those elementwise accesses work - the lvalues are still of type
> X here or are new lvalues implicitly formed and fall under the
> other wordings?
I think there is no wording for elementwise copy.
My understanding is that the
"...an aggregate or union type that includes..."
wording above is supposed to define this via an lvalue
access with aggregate or union type. It blesses the
implied access to the elements via the access with
an lvalue which has the type of the aggregate.
> Can I thus form an effective type of X by
> storing it's subobjects at respective offsets (ignoring padding,
> for example) and can I then use an lvalue of type 'X' to access
> the whole aggregate?
I think this is defined behavior. The subjects get
their effective types via the individual stores and then
the access using lvalue of type 'X' is ok according to
the "..an aggregate or union type that includes.."
rule.
Martin
