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: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Thu, 15 Aug 2024 17:08:12 +0100
Organization: A noiseless patient Spider
Lines: 174
Message-ID: <v9l95b$10ogv$1@dont-email.me>
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> <87y14xsvnh.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 15 Aug 2024 18:08:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fcb44464f1714e8680386692a2a2f20c";
	logging-data="1073695"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187/vTZ+G623+OdigzzKVG1"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qkveziISkFZPOFfiM8zRy8C4xUw=
Content-Language: en-GB
In-Reply-To: <87y14xsvnh.fsf@bsb.me.uk>
Bytes: 7904

On 15/08/2024 15:33, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 15/08/2024 09:43, Tim Rentsch wrote:
>>> Bart <bc@freeuk.com> writes:

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

Sorry, what language does the right-hand column pertain to? /Any/ 
language that has call-by-reference, or Tim's hypthetical language?

Or any that could be used to prove him right?

In general there is no reason, in a language with true 
call-by-reference, why any parameter type T (which has the form U*, a 
pointer to anything), cannot be passed by reference. It doesn't matter 
whether U is an array type or not.


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

In my original post it was G() that was C emulating pass-by-reference.

It wasn't stated that p was an array pointer, only pointer, but it 
doesn't make any difference in H which we can assume is not C, and 
therefore doesn't have C's hangups about arrays and pointers.


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

Neither of you have explained this well. Are you both projecting C's 
craziness with arrays and pointers onto this hypothetical language?

If so, then if this fantasy language has true pass-by-reference, then 
let it have real value-arrays too!

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

I illustrated some conveniences which C's array-passing idiom which 
match those of true pass-by-reference.


>> since it effectively applies & to the argument.
> 
> No.  Passing a reference is /not/ like using & to pass a pointer.

Funny, in my language that is EXACTLY how it is implemented. Instead of 
my writing:

   F(&x) and in F having to write: *x

you instead write:

   F(x) and in F you write: x

So it will insert & and * operators for you. Why,  how would /you/ do 
it? (I'm talking about this level of language; higher level ones might 
do everthing with references anyway, and might not have & or * operators.)



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

Yes, as I said, I concentrate on the ones which allowed you to write 
F(A), and A[i] inside F, just like pass-by-reference, rather than F(&A), 
and (*A[i]) inside F. Did I claim it was full by pass-by-reference?

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

It doesn't matter; any call-by-reference worth its salt will allow you 
to change variables in the caller. That's half the point it!

C doesn't have A=B syntax for arrays, but it can do memcpy for the same 
effect.


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

What pointer assignment? You're mixing actual C with fantasy C. You 
can't do that: if you add array assignment to C, then it changes everything.

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

These were my original comments on the subject made to DB:


DB:
 >. In C, there is no "pass by reference" or "return by reference".  It 
is all done by value.

BC:

 >Arrays are passed by reference:

 >  void F(int a[20]) {}

 >  int main(void) {
 >    int x[20];
 >    F(x);
 >  }

========== REMAINDER OF ARTICLE TRUNCATED ==========