Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Regarding assignment to struct
Date: Wed, 7 May 2025 09:37:57 +0200
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <vvf2kl$sq8k$1@dont-email.me>
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> <vvame5$ppqp$1@dont-email.me>
 <87jz6uhkgo.fsf@nosuchdomain.example.com> <vvdhb2$3m8gn$1@paganini.bofh.team>
 <vvdleo$3if4o$1@dont-email.me> <_jtSP.16069$v2h6.13921@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 07 May 2025 09:37:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="967fd94fba9916c9ca6ff2f7cc26a5cf";
	logging-data="944404"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198nP2mUy5qRQBEPYPmH2yA64++pp/3lEo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:DEANygPAQP5o2WvUB16uH1D8SB8=
In-Reply-To: <_jtSP.16069$v2h6.13921@fx14.iad>
Content-Language: en-GB

On 06/05/2025 21:22, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 06/05/2025 19:36, Waldek Hebisch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Andrey Tarasevich <noone@noone.net> writes:
>>>> [...]
>>>>>     #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.
>>>>
>>>> I believe it does.  pc points to an element of an object with
>>>> temporary lifetime.  The value of pc is then used after the object
>>>> it points to has reached the end of its lifetime.  At that point,
>>>> pc has an indeterminate value.
>>>>
>>>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>>>> the object the pointer points to (or just past) reaches the end of
>>>> its lifetime, the behavior is undefined. The representation of a
>>>> pointer object becomes indeterminate when the object the pointer
>>>> points to (or just past) reaches the end of its lifetime."
>>>
>>> Note commas above.  Assignment to pc and call to printf are parts
>>> of a single expression, so use of pc is within lifetime of the
>>> temporary object.
>>>
>>
>> I must admit I had not noticed that detail.
> 
> That would get an immediate downcheck during review for exactly
> that reason.

Of course.  In fact, if someone presented such code for review (and 
assuming I noticed the commas!) I'd have to consider whether it was done 
maliciously, intentionally deceptively, due to incompetence, or 
smart-arse coding.  In all my C coding experience, I can't recall ever 
coming across a single situation when I thought the use of the comma 
operator was appropriate in the kind of code I work with.

Other people, projects, and teams work with different standards, 
different requirements, and different kinds of code - there are a lot of 
things that are common practice in some C coding that are strongly 
rejected in my field (and perhaps vice versa).  So I am not suggesting 
that the comma operator is always bad in C - just that it is pretty much 
always bad in my line of work.

And of course Andrey was using it here to make a specific point in a 
discussion about C details, rather than real-life code.