Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Regarding assignment to struct
Date: Mon, 05 May 2025 07:14:17 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <86wmav401y.fsf@linuxsc.com>
References: <vv338b$16oam$1@dont-email.me> <vv4j9p$33vhj$1@dont-email.me> <86plgo7ahu.fsf@linuxsc.com> <vv9hu7$3nomg$1@dont-email.me> <20250505111213.00004b55@yahoo.com> <vv9stv$2i8j$1@dont-email.me> <20250505120145.000014f8@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 05 May 2025 16:14:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b2f20e442295d938e3644788cf940be7"; logging-data="629572"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19iAkNEmTaglce/1vPCIfwTg1DmXUjcQwk="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:uzJvTOek2IhHllG53SvhDyCHaZ0= sha1:F5sILqXHjIvXSfkANlokOnHI6Po=
Xref: csiph.com comp.lang.c:393176

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 5 May 2025 01:29:47 -0700
> Andrey Tarasevich <noone@noone.net> wrote:
>
>> On Mon 5/5/2025 1:12 AM, Michael S wrote:
>>
>>> According to my understanding, you are wrong.
>>> Taking pointer of non-lvalue is UB, so anything compiler does is
>>> conforming.
>>
>> Er... What?  What specifically do you mean by "taking pointers"?
>>
>> The whole functionality of `[]` operator in C is based on pointers.
>> This expression
>>
>>    (a = b).a[5]
>> [...]
>> is already doing your "taking pointers of non-lvalue" (if I
>> understood you correctly) as part of array-to-pointer conversion.
>> And no, it is not UB.
>>
>> This is not UB either
>>
>>    struct S foo(void) { return (struct S) { 1, 2, 3 }; }
>>    ...
>>    int *p;
>>    p = &foo().a[2], printf("%d\n", *p);
>
> That is not UB:
> int a5 = (a = b).a[5];
>
> That is UB:
> int* pa5 = &(a = b).a[5];
>
>> So, what you are basing your "UB" claim on is not clear to me.
>
> If you read the post of Keith Thompson and it is still not clears to
> you then I can not help.

Under C11 semantics, both

   int a5 = (a = b).a[5];
   
and

   int* pa5 = &(a = b).a[5];

have well-defined behavior.  The undefined behavior of the
upthread example comes later, only after the statement assigning
to the pointer (or here, initializing) completes.  It isn't
taking the address with & that has undefined behavior;  it is
using the stored pointer value in a subsequent statement, /after
the full expression containing the & operator has completed/,
that results in undefined behavior.