Re: Regarding assignment to struct

On 08/05/2025 21:45, Tim Rentsch wrote:

Andrey Tarasevich <noone@noone.net> writes:
 

 

And that's probably what led to difference in interpretation
between GCC and Clang.

 I suspect the implication actually goes the other way.  It is
because what gcc has done (past tense) violates the rules of the C11
standard that someone had the bright idea that the C standard should
be changed to allow this stupidity.
 

Modification of the temporary is "prohibited" (as UB), but
modification of the overlapped named object is not.  The
consequences can be quite surprising.

 In my view the problem is not that what is allowed is unclear, but
that the whole idea of possibly overlapping objects is a crock.
It's a sad statement on the quality of gcc that it does the wrong
thing even when -std=c11 and -pedantic are given as compilation
options.  Bleah.

While I think it is important that compilers try to follow the C standards (at least when you specify conforming modes), are there any potential realistic consequences of this?
Posters here have gone far out of their way to make hypothetical code that demonstrates this flaw in gcc without invoking undefined behaviour.   Is there any risk that anyone would come across this in real code?
In addition, is it reasonable to suppose that C programmers that have not studied the C standards here would be expecting the behaviour of gcc, or the behaviour of clang here?  Certainly if /I/ saw "pc = &(a = b).a[5]" prior to this thread, I would expect the contents of the struct "b" to be copied to the memory of the struct "a", and "pc" set to point to the member of the array within "a".  I would expect the code to work as gcc works, and would find clang's behaviour completely unexpected.  I would be surprised if I were alone in that.
So to me, it makes sense that the C standard has changed to support a more sane approach to such situations.  It would be unreasonable to change it to guarantee the sensible behaviour - that would mean compilers like clang that generated technically correct but surprising (to many) code would now be wrong.
(gcc's behaviour is also more efficient, but of course correctness trumps efficiency every time.)