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: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Thu, 15 Aug 2024 15:33:38 +0100
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <87y14xsvnh.fsf@bsb.me.uk>
References: <v66eci$2qeee$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk>
	<v6m716$1urj4$1@dont-email.me> <87ikxconq4.fsf@bsb.me.uk>
	<v6n8iu$24af0$1@dont-email.me> <20240711115418.00001cdf@yahoo.com>
	<v6oamt$2d8nn$1@dont-email.me> <v6oct4$2djgq$2@dont-email.me>
	<v6of96$2ekb0$1@dont-email.me> <v6ovfc$2hcpf$1@dont-email.me>
	<v6p4hf$2icph$1@dont-email.me> <v6qgpu$2t6p7$3@dont-email.me>
	<v6r33m$30grj$1@dont-email.me> <20240712154252.00005c2f@yahoo.com>
	<86o7717jj1.fsf@linuxsc.com> <v6ti10$3gru4$1@dont-email.me>
	<v78af7$1qkuf$1@dont-email.me> <20240717163457.000067bb@yahoo.com>
	<v78piu$1su4u$1@dont-email.me> <86a5hep45h.fsf@linuxsc.com>
	<v9ktep$v5sk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 15 Aug 2024 16:33:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a2a6b85c612cf435cb3baf8dd64ec077";
	logging-data="1027619"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+S+KuGQyjVX576LacZjJRFxc4jdbT4UTI="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:Vn6rU3zI9FRnawS6X+wWM2AsBxU=
	sha1:9m6bsIjZnySseU5XAKGbVcrX6TQ=
X-BSB-Auth: 1.2494e02a2cc7a7a58489.20240815153338BST.87y14xsvnh.fsf@bsb.me.uk
Bytes: 5999

Bart <bc@freeuk.com> writes:

> On 15/08/2024 09:43, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>>
>> [on comparing array arguments in C with call-by-reference]
>>
>>> [...] the differences [between C rules and true call-by-reference]
>>> can be summarised here;  [...]
>>>
>>>                                   Call     Array access in callee
>>>
>>>      C call-by-value              F(A)     A[i]
>>>
>>>      true call-by-reference       H(A)     A[i]
>>>
>>> What the user has to write is what's important, and here it is clear
>>> that they write the same thing [in the two cases shown].
>>
>> The comparison above is misleading because it is incomplete.
>> Let's compare the two modes more fully:
>>
>>
>>                          C call-by-value         call-by-reference
>>                          ===============         =================
>>    at call:
>>
>>      (array argument)    F(A)                    H(A)
>>
>>      (pointer argument)  F(p)                    (disallowed)
>
> My posts were about passing *arrays* and the fact that C's pass-by-value
> was remarkably similar to pass-by-reference.

Which is why, presumably, you didn't show the differences.  Your
post was all polemic not part of a collegiate discussion of the
similarities and differences.

> However your entry for pointers is not correct:

No, the entry is correct.  H(p) would be (is?) disallowed when H's
parameter is a reference to an array.

> you can pass pointers by
> reference (in C, it means passing a T** type instead of T* to emulate
> that).

H's parameter is /not/ what you claim "emulates" a reference to a
pointer -- it's a hypothetical reference to an array.

Maybe you missed what Tim was doing.  He is showing a fuller comparison
for one F and one H.  A different function could, in this hypothetical
C with call-by-reference, be passed a pointer, but then it could not be
passed an array.

>>      (null argument)     F(0)                    (disallowed)
>
> Pass-by-reference necessarily requires an lvalue at the call-site

Yes, that is one of the differences you failed to illustrate.

> since it effectively applies & to the argument.

No.  Passing a reference is /not/ like using & to pass a pointer.

>>    inside function:
>>
>>      (access)            A[i]                    A[i]
>>
>>      (update)            A[i] = ...              A[i] = ...
>>
>>      sizeof A            (pointer size)          (array size)
>
> That's one of the small differences. But you only get the array size in a
> language where the array type includes its length. Otherwise, you only get
> it if it's part of the parameter type.
>
>>      A++                 (changes A variable)    (disallowed)
>
> (In my language ++A is allowed. I'm not sure why, it's likely a bug.)

In the hypothetical C with call-by-reference, it's another difference
you chose not to show.

>>      A = (new value)     (changes A variable)    (disallowed)
>
> This is allowed too in my language, if the array has a fixed size. It
> reassigns the whole array.

Your language (for which we have no reference material) is beside the
point.  This is another difference you failed to point out in your
comparison.

> In C you can't do A = B for other reasons, since arrays aren't manipulated
> by value.

One way or another, this is a difference you failed to illustrate.  If
this hypothetical C is very close to C then the difference is as Tim
posted.  But in a another quasi-C that permits array assignment there
would still be a difference: the pointer assignment would be disallowed
but the array assignment (by reference) would be permitted.

....
>> The more complete comparion illustrate why C semantics should not
>> be thought of as call-by-reference.
>
> It was made clear more than once that it wasn't exact
> call-by-reference.

So why did you give only one side of the comparison?  You have nothing
to lose by being open about the differences if your objective is an
open, collegiate discussion of C.  By presenting a polemic, you make the
whole exchange more antagonistic than it needs to be.

> It was also made clear that there were enough similarities that adding real
> call-by-reference arrays to C would buy you very little.

-- 
Ben.