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: Fri, 30 May 2025 10:50:56 +0200
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <101brhg$dckn$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>
 <vvf2kl$sq8k$1@dont-email.me> <1019l3t$3rqk1$6@dont-email.me>
 <101ac2r$me2$2@dont-email.me> <g84_P.377134$vvyf.152232@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 May 2025 10:50:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2deb49b57587f08ddceb63c074c1f447";
	logging-data="438935"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19pGqfqMzif7Kcpm6rUo1NHCQvTI6Io2Uw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:P8T2IipaKw9VOB460QxREW7mVKQ=
In-Reply-To: <g84_P.377134$vvyf.152232@fx18.iad>
Content-Language: en-GB

On 29/05/2025 23:15, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 29/05/2025 14:49, Andrey Tarasevich wrote:
>>> On Wed 5/7/2025 12:37 AM, David Brown wrote:
>>>>>
>>>>> 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.
>>>
>>> Wow! That's catastrophically bad.
>>>
>>> As it has been stated many times before, both C and C++ are programming
>>> languages that embrace both statement-level and expression-level
>>> programming. Expression-level programming (e.g. where `?:` is used for
>>> branching and `,` for sequencing) is a very valuable and massively
>>> important programming paradigm in these languages. The fact that
>>> elaborate expression-level programming is not in nay way abandoned or
>>> shunned today is pretty obvious in C++, since C++ took major steps
>>> lately to develop its expression-level capabilities. But it has always
>>> been and will always remain important in C as well.
>>
>> No, expression-level programming has always been and will likely always
>> remain a very minor part of C programming.  Yes, some people make use of
>> the comma operator.  Some people do so extensively - and they are often,
>> but not necessarily, considered "smart-arse" programmers rather than
>> "smart" programmers.  If the comma operator were removed from the C
>> language, I guess some 95% of programmers would barely notice - at
>> worst, they would have to add an extra line inside an occasional "for"
>> loop.  (The tertiary operator is used much more.)
> 
> And sometimes, excessive use of the comma operator causes
> compiler failures.

That is also an issue in the world of small-systems embedded programming.

While a lot of it these days is on ARM, and most of that is done using 
gcc, there are hundreds of C compilers of varying quality (and price, 
which is no indication of quality) for embedded systems.  Many of these 
other toolchains have bugs, non-conformities, inconsistencies and 
weaknesses.  (gcc is not perfect either!)  People programming for 8-bit 
and 16-bit microcontrollers using such tools will - and should - use a 
conservative subset of the C language.  Obscure and rarely used features 
of the language will be avoided, and code will be written in a simpler 
manner.  You don't write code in a way that increases the risk of 
catching a bug in a poorly tested part of the compiler, or in a way that 
might lead to unexpectedly inefficient results.

With 32-bit ARM now dominating the industry, along with more reliable 
tools (primarily gcc, with clang a distant second), there is much less 
need to pander to flaws in the toolchain but you still need to consider 
weaknesses in humans.  When you are writing software that is intended to 
run continuously without problems for years, or where a misunderstanding 
by a new maintainer a decade later can lead to safety risks, you don't 
write "cool" code!

It is well known that "Debugging is twice as hard as writing the code in 
the first place. Therefore, if you write the code as cleverly as 
possible, you are, by definition, not smart enough to debug it."  I 
would also say that understanding and maintaining other people's code is 
often a lot more than twice as hard as writing the code yourself.  I aim 
to code accordingly.

> 
> cfront generated the comma operator extensively, and expression trees
> would grow to very large sizes.   There was a bug in PCC (for the
> 88100) where it would run out of temporary registers while generating
> code for some cfront generated comma expressions (which were -far- from
> human readable).    I had to fix the temporary register allocation
> code in PCC to spill registers when the sethi-ullman number for an
> expression exceeded the number of registers.
> 
> That was circa 1990, and I've generally not found any arguments
> favoring their general use persuasive in the years since, including
> Andrey's and Kaz's responses recently posted here.
> 
> The simple fact that experienced programmers that read this usenet
> newsgroup missed the comma operators in the original example speaks
> volumes.
> 

Of course people are experienced in different things - "programming", 
even when limited to a single language, is a broad field.