Path: ...!3.eu.feeder.erje.net!feeder.erje.net!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, 29 Aug 2024 23:45:47 +0100
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <vaqtms$55ns$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <vah4hr$2b9i8$5@dont-email.me>
 <vahngt$2dtm9$1@dont-email.me> <87r0abzcsj.fsf@bsb.me.uk>
 <vai1ec$2fns2$1@dont-email.me> <874j75zftu.fsf@bsb.me.uk>
 <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk>
 <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk>
 <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk>
 <vaps06$3vg8l$1@dont-email.me> <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> <87h6b39imm.fsf@nosuchdomain.example.com>
 <vaqp83$4jjo$1@dont-email.me> <878qwf9ec4.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Aug 2024 00:45:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="174259085da7cb67cacc3eba8e8469e6";
	logging-data="169724"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zA3dB1c6iIPfvECvdC/Fg"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:pwF00kzh45Vhx/WXT2q0zkQ2FPg=
In-Reply-To: <878qwf9ec4.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 4528

On 29/08/2024 23:03, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/08/2024 21:30, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> So what exactly is different about the LHS and RHS here:
>>>>
>>>>      A = A;
>>> The RHS is evaluated to determine the current value stored in the
>>> object
>>> named A.  The LHS is evaluated to determine the object that's designated
>>> by the name A; its current value is irrelevant.
>>
>> Sure, but the same thing happens on both sides: one ends up performing
>> a Read via that Lvalue, and the other does a Write via that Lvalue.
> 
> The read is done by converting the lvalue to its value, which is not an
> lvalue.  Please read the discussion of "lvalue conversion" in the C
> standard.
> 
>>> In C terms, the RHS undergoes *lvalue conversion*, where an expression
>>> that's an lvalue is converted to the value stored in the designated
>>> object.  The LHS does not undergo lvalue conversion.
>>>
>>>> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A'
>>>> is also valid, there is a hidden mismatch in indirection levels
>>>> between left and right. It is asymmetric while in C it is symmetric,
>>>> although seem to disagree on that latter point.)
>>> Because BLISS, unlike C, does not have implicit lvalue conversion;
>>> the
>>> prefix "." operator performs explicit lvalue conversion.  I presume the
>>> "." operator isn't specific to assignments.
>>
>> But it must have that conversion on the LHS, otherwise it's A's
>> address that is written to rather than its value, which doesn't make
>> sense. That's why I said it was asymmetric; the RHS needs an explicit
>> operator, the LHS doesn't.
> 
> No, the address isn't written.  The object is written.
> 
> The RHS evaluation determines the value currently stored in the object.
> The LHS evaluation does not.  That's the asymmetry.
> 
> In BLISS, the evaluation of the expression A determines the object that
> the name A designates.  In C, it can either do that *or* it can extract
> the value currently stored in that object.

So if C was to behave the same way as BLISS:

     int a, b, c;

     b = 23;           // sets b to 23
     a = *b;           // sets a to that 23 in b
     c = *a + *b;      // sets c to 46

     a = b;             // attempts to set a to b's address (&b)

You would say that this is now symmetric, but C normal C wasn't?

I get you...





.... not really! We'll just have to disagree. My comments are based on 
having implemented this stuff myriad times on multiple targets, but I 
must have obviously have been misunderstanding it all that time.

Opening a drawer A to put something in, is a totally different thing to 
opening the same drawer A to take something out; of course!