Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Fri, 13 Sep 2024 14:18:53 +0100
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <vc1e3s$s2sa$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <vbci8r$1c9e8$1@paganini.bofh.team>
 <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team>
 <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team>
 <vbhbbb$1blt4$1@dont-email.me> <87tteqktr8.fsf@bsb.me.uk>
 <vbkjqk$201ms$1@dont-email.me> <87ttenk2nq.fsf@bsb.me.uk>
 <vbps3c$31s4d$1@dont-email.me> <vbtik7$38tme$1@paganini.bofh.team>
 <vbuj67$733i$2@dont-email.me> <87ikv0y864.fsf@nosuchdomain.example.com>
 <vbvgud$cspe$1@dont-email.me> <875xr0y4re.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 Sep 2024 15:18:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6d9b666ce7e3bf261820c8472c068fb6";
	logging-data="920458"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189zi3ioeixx82RUD83AUHy"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2j1a17Wzp9IY1f2GahnVXLFbJgo=
In-Reply-To: <875xr0y4re.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 3848

On 12/09/2024 21:51, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 12/09/2024 20:38, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> It's not that complicated, not with C anyway.

> Agreed.  Let's stop doing that.  (Your specific statement that there are
> *four* categories triggered a lot of the "too much".)

I actually said 3-4 categories, depending on when index operations get 
turned into pointer operations. In C source they don't, but it might 
conceptually be in the mind of whoever is writing the C source.

> Upthread, you wrote:
> 
>      That's the only thing that needs to 'change', which I don't think is
>      onerous anyway.
> 
> Would you like to clarify what you think needs to change?

That was in reply to this (I've capitalised 'changing'):

WH:
 >"To be more precise, gcc parser when seeing a variable
creates read reference to this variable.  When parser realizes that
already recognized part of expression is the left hand side of an
assignment it converts it to write access.  So your approach is
no worse than gcc.  But it creates troubles, process of CHANGING
subexpression with read references into write access is more
complicated than replacing read instruction by write instruction."

I put my 'change' in quotes since I didn't believe any such change is 
necessary. But if somebody or something deems it so then, in C, that 
would only apply to one lvalue on the LHS of an assignment.

WH was criticising the approach of initially dealing with LHS/RHS, 
lvalue/rvalue, the same way, then making any 'changes' later.

I gave an example of a LHS that might appear in some languages that had 
MULTIPLE lvalue terms on the left of an assignment, that could be nested 
within a complex expression, where that appoach gives very little trouble.

But I can see you're mainly concerned with scanning my posts to see if 
there's any divergence from the exact wording of the C standard, even 
though the discussion is a little wider than that in crossing language 
boundaries, and includes implementation details that are beyond the 
scope of the standard anyway.

All I can say is that comp.std.c is that way --->