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: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Tue, 10 Sep 2024 15:24:09 +0100
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <87ttenk2nq.fsf@bsb.me.uk>
References: <vab101$3er$1@reader1.panix.com> <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>
	<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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 10 Sep 2024 16:24:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="41cd442c75b68753892361e16025f2ff";
	logging-data="3148869"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+IXowsc8r2KphNoQQaJ7Dp5MgQzJlG96c="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:4fccs+TW/L6AGvKMgMn4aDHVSpE=
	sha1:0YX6SR7nNDcfLaiVG2hjyOro7o8=
X-BSB-Auth: 1.17ad3cdf331f3b290c26.20240910152409BST.87ttenk2nq.fsf@bsb.me.uk
Bytes: 4033

Bart <bc@freeuk.com> writes:

> On 08/09/2024 17:14, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> On 07/09/2024 02:44, Waldek Hebisch wrote:
>>>> Bart <bc@freeuk.com> wrote:
>>>>> On 06/09/2024 11:19, Waldek Hebisch wrote:
>>>>>> Bart <bc@freeuk.com> wrote:
>>>
>>>>> (You can balance it out by by requiring ASSIGN(&A, &B)!)
>>>> This would not work in general, as I wrote it, the following are
>>>> valid:
>>>> assign(&a, 42)
>>>> assign(&a, a + 1)
>>>> but the second argument has no address, so your variant would not
>>>> work.
>>>
>>> I believe that C's compound literals can give a reference to a+1:
>> Is there no part of C you can't misrepresent?
>
> Is nothing I write that you will take issue with?

Count the number of posts you've made in, say, the last month.  Count
the number of them to which I have replied.  Does the answer your
question?

>>>    #include <stdio.h>
>>>
>>>    void assign(int* lhs, int* rhs) {
>>>        *lhs = *rhs;
>>>    }
>>>
>>>    int main(void) {
>>>        int a=20;
>>>
>>>        assign(&a, &(int){a+1});
>> This is simply an anonymous object.  You could have used a named object
>> and it wold not have been any further from being a "reference to a+1".
>
> I suggested a 'assign()' function could have balanced parameters by
> requiring:
>
>     asssign(&A, &B);
>
> Someone objects that you can't in general apply & to arbitrary, unnamed,
> transient, intermediate values such as 'a + 1'.

or even just 1.

> I showed how you could do that using anonymous compound literals which
> avoids having to create an explicit named temporary which in standard C
> would need to be outside of that assignment call.
>
> But you apparently have a problem it.

Because you called it a reference to a+1.  The reference is to an
object.

I don't know if you were deliberately twisting the term because you are
now 100% committed to some false symmetry in assignments, or whether you
are just very loose in your use of terms, but rvalue expressions (C does
not really use the term, but it's better than non-lvalue expressions)
can't have "references" to them.  That was all that Waldek Hebisch was
saying.  Did you think for a second that he did not know that if you put
an int value into an object you can take the pointer to that object?

> Or more likely you have a problem with me.

-- 
Ben.