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: Thu, 12 Sep 2024 12:00:18 +0100
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <vbuhk1$733i$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <871q27weeh.fsf@bsb.me.uk>
 <20240829083200.195@kylheku.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> <vbj6ii$1q6mh$1@dont-email.me>
 <20240908115827.00007521@yahoo.com> <vbju6l$1sqao$2@dont-email.me>
 <87zfoikve1.fsf@bsb.me.uk> <vbkka9$201ms$2@dont-email.me>
 <vbnv43$2igdn$1@dont-email.me> <87zfofk32t.fsf@bsb.me.uk>
 <vbptr4$31s4d$2@dont-email.me> <87bk0vjbvz.fsf@bsb.me.uk>
 <vbrp96$3gqes$2@dont-email.me> <87tteliwgh.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2024 13:00:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3a3e703b62fd17d38a4df729837e6247";
	logging-data="232562"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19D09SfzyMR68wp1bla7dCF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tLDqQeTrXCdYCegoSXOSy+INK8o=
In-Reply-To: <87tteliwgh.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 4730

On 12/09/2024 00:47, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 11/09/2024 01:02, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> Sorry, did your remark above suggest I don't know what an lvalue is?
>>> That seemed like the obvious explanation for the incorrect information
>>> you gave.  Did you post it /knowing/ what other kinds of things are
>>> lvalues in C just to confuse people?
>>
>> Which incorrect explanation was that?
>>
>> I merely said that LHSs of assigments fall into these categories:
>>
>>     A = Y;         // name
>>     *X = Y;        // pointer
>>     X[i] = Y;      // index
>>     X.m = Y;       // member select
> 
> Yes, that incorrect explanation.

I dispute that. What I said is very broadly correct. But in this 
newgroup you do like to nitpick.

So to you, it is of the greatest importance that somebody doesn't just 
know about those four categories that they will be reading and writing 
all the time in C code, but also know about:

   (int){A} = Y;

which they will encounter approximatey never. And it is also vital they 
they consider:

    (A) = (Y);

a distinct category. There might be a case for this for '(Z, A) = Y;' 
but that isn't allowed anyway. So it only applies to superfluous 
parentheses.




> 
>> Clearly I mean VALID LHSs, otherwise they wouldn't be LHSs of assignments!
>>
>> I've since learnt about a couple of other possible categories; one is with
>> compound literals like '(int){42} = 0'.
> 
> Along with (a) _Generic expressions (where the selected arm is an
> lvalue)


The _Generic forms reduce down one of those four. It is more like a 
macro, and if you're going to start with macros, there are unlimited 
categories that can be created. If this is merely about syntax, then why 
not?

(I'd also like to see an actual usecase for _Generic on the LHS of an 
assignment. Perhaps one where there is a matching (symmetric?) _Generic 
on the RHS?)

> and (b) expressions of the form X->m.

Are there any circumstances where X->m does something different from (*X).m?


>> (I don't count (A), ((A)) etc as a
>> separate category; come on!)
> 
> Don't give me "come on!".  I was counting forms in the same way that you
> were when I said I could think of three more.  I was not counting
> parentheses.

Keith mentioned this form.

> 
>> The other is 'X.m' but when .m is a bitfield;
> 
> What makes X.m = Y, where m is a bitfield, an extra category?  It fits
> the X.m = Y pattern perfectly well.
> 
>> although this has the same
>> same syntax as above, internally it's somewhat different.
> 
> Your categories were syntactic.  You were describing forms.

Not entirely. There is behaviour associated with them.

Most LHS terms can have & applied in an rvalue context for example; 
bitfield accesses can't. So it's something a user of the language needs 
to know about.

And internally, my ASTs (where bitfields are supported) use a different 
node type when X.m is a bitfield rather than a regular access.