Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Fri, 13 Sep 2024 00:46:35 +0100
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <87bk0sigf8.fsf@bsb.me.uk>
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> <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>
	<vbuhk1$733i$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 13 Sep 2024 01:46:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b8e7daafe9c4d62f654f00a3ff91b56f";
	logging-data="525473"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18t8HuOfHuWezitos+c0tbwckp2ksOcLAs="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:fRUqVZI5dwBrL3+V2nV3fahaFX0=
	sha1:XaiO3YsOvcTjGuYJECDW82TPI1s=
X-BSB-Auth: 1.70b7e1903c63110059ce.20240913004635BST.87bk0sigf8.fsf@bsb.me.uk
Bytes: 6319

Bart <bc@freeuk.com> writes:

> 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.

Someone who wants to write p->m = 42 would not consider it nitpicking if
your compiler did not accept that form of LHS.

But I agree I was simply correcting a small error.  Why did you not just
say "yes, I forgot a few cases"?

> 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;

You see why I wonder if you had a political career?  This is pure spin.
There is no technical argument here, just an attempt to mock someone
pointing out a truth.  I never even suggested that it was important,
just that it was a missing case.  And, still spinning away, you ignore
X->m which /is/ important and was also missing.

> which they will encounter approximatey never. And it is also vital they
> they consider:
>
>    (A) = (Y);
>
> a distinct category.

More spin.  There is nothing vital about it at all, and no one ever said
there was.  In fact I explicitly stated that I was ignoring such
details.

> 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 would reduce down to one of the six or seven (dependin how we want ot
count), not to your four.  Anyway, you were not listing "reduced" forms
but the valid shapes for left hand sides.

> 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?

Are there cases where X[i] does something different to *(X+i)?  You felt
the need to distinguish them despite the fact that they are equivalent
by definition.

>>> (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.

Your reply was to me.

>>> 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.

You were describing the forms of assignment.  If you want to consider
"things you can't do with some valid left hand sides", bitfields are not
alone in being special[1], but there is no reason to single them out
when just being left hand sides.

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

[1] in case you accuse me of teasing again, your first form of LHS, A =
Y, can't be the operand of & if A is declared with storage class
register.

-- 
Ben.