Re: Regarding assignment to struct

On Mon 5/5/2025 10:20 AM, Michael S wrote:

>
Here's a version of the same code that corrects the above distracting
issues
>
    #include <stdio.h>
>
    struct S { int a[10]; };
>
    int main()
    {
      struct S a, b = { 0 };
      int *pa, *pb, *pc;
>
      pa = &a.a[5],
      pb = &b.a[5],
      pc = &(a = b).a[5],
      printf("%p %p %p\n", (void *) pa, (void *) pb, (void *) pc);
    }
>
This version has no UB.
>

 
It's only not UB in the nazal demons sense.

UB is UB only in the nasal demons sense. UB means that "This
international standard imposes no requirements on the behavior". That
is, anything could happen, at least as far as the standard is concerned.
Code with undefined behavior should not be able to produce nasal demons
because there's no such thing as nasal demons (I think). However, if
they did exist, producing them would not violate any requirements
imposed by the standard, because it quite explicitly imposes none on
such code.

It's UB in a sense that we can't predict values of expressions
like (pa==pc) and (pb==pc). ...

Why not? Because of the comma operators, the lifetime of the temporary
extends all the way till the end of the printf() call, long enough to
make use of pc in that call safe.

... I.e. pc is completely useless. In my book
it is form of UB.

If the problem were only that there's no restrictions on the value of an
expression, but that the code is otherwise safe to use, that would be
indicated by a much weaker term: "unspecified value".  Calling it "a
form of UB" would serve no useful purpose.