Re: Undefined behavior due to 6.5.16.1p3

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 10 Mar 2015, Robbert Krebbers wrote:

> On 03/10/2015 05:44 PM, Robbert Krebbers wrote:
> > On 03/10/2015 05:18 PM, Martin Sebor wrote:
> > > I suspect every compiler relies on this requirement in certain
> > > cases otherwise copying would require making use of temporary
> > > storage. Here's an example:
> > Thanks, this example is indeed not already undefined by effective types,
> > nor 6.2.6.1p6.
> Now to make it more subtle. As far as I understand 6.5.16.1p3, undefined
> behavior can already occur without the use of union types or malloc. For
> example:
> 
>   struct S { int x, y; };
>   int main() {
>     struct S p = (struct S){ .x = 10, .y = 12 };
>     p = (struct S){ .x = p.x, .y = 13 };
>     return p.x;
>   }
> 
> is undefined AFAIK.

I don't see why that would be undefined.  The value stored in p isn't read 
from something overlapping with p, it's read from the compound literal 
object that in turn was initialized with { .x = p.x, .y = 13 }.

Similarly, in the union case in 
<https://gcc.gnu.org/ml/gcc/2015-03/msg00092.html>, if you had

struct A f (struct A arg) { return arg; }

and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be 
undefined (see 6.8.6.4 and GCC PR 43784).

-- 
Joseph S. Myers
joseph@codesourcery.com