Deutsch   English   Français   Italiano  
<v9m7hf$15903$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Fri, 16 Aug 2024 01:46:38 +0100
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <v9m7hf$15903$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> <86msldo4e7.fsf@linuxsc.com>
 <v9lv3e$1465l$1@dont-email.me> <20240815161923.408@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 16 Aug 2024 02:46:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="41b943bbe22b81dd70cf2db8d8e89fb0";
	logging-data="1221635"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19sH5Ox/RHfYKhT0VKf8uq2"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0JAuo8HhCbEICNVTVQHTyCjcM+w=
Content-Language: en-GB
In-Reply-To: <20240815161923.408@kylheku.com>
Bytes: 5178

On 16/08/2024 00:29, Kaz Kylheku wrote:
> On 2024-08-15, Bart <bc@freeuk.com> wrote:
>> On 15/08/2024 22:36, Tim Rentsch wrote:
>>> I see.  So your point is, if we ignore all the ways that the two
>>> modes are different then they are exactly the same.
>>>
>>> Brilliant deduction, Dr. Watson.
>>
>> So your approach is to totally ignore all the ways that the two modes
>> are identical.
> 
> Almost any two different things have some attributes that are identical.
> If we consider a bicycle and a fish, we can probably come up with common
> attributes.
> 
> Passing pointers by value similar to call-by-reference, but also
> different.

I'm going to show a demo in my language because C doesn't support both 
by-value and by-reference.

However, here is the F function written in C (one point of difference is 
that my 'int' is 64 bits):

   void F(int* A) {
       int i;
       A[i]=0;       // same as (A+i)=0
   }

The above uses the C idiom for passing and using arrays, which I will 
try and emulate here:

     proc F(ref int A) =           # equivalent to C func above
         int i
         (A+i-1)^:=0               # ptr-relative must be 0-based
     end

     proc H([]int &A) =            # pass-by-reference
         int i
         A[i]:=0
     end

     proc main =
         [10]int A

         F(cast(&A))               # Pass A to F, C-style
         H(A)                      # Pass A to H, by-reference
     end

(What I can't emulate is the call to F which in C looks like F(A), 
exactly like the call H.)

So Tim, and apparently you, claim there are no points of similarity, or 
that they don't have any bearing on anyway. Well here are the bodies of 
F and H when translated to x64 assembly, excluding entry/exit code:

     mov u64 [D10+D3*8-8], 0         # body of F ('i' resides in D3)

     mov u64 [D10+D3*8-8], 0         # body of H

You can see that they are identical. And here the two calls:

     lea  D10, [D14+t.main.a]
     call t.f
     lea  D10, [D14+t.main.a]
     call t.h

That's quite remarkable: the guts of a call-by-value function and its 
call, being identical to that of a call-by-reference function and /its/ 
call.

A bit like comparing the insides of a bicycle and a fish, and finding 
they are the same!



> 
> The program can calculate a bad pointer and pass that by value.
> 
> Call-by-reference implementations can take measures to ensure that
> a a bad reference is not passed.

Yes, both my G and H examples have better type-checking than the F 
function which was idiomatic C (you can see I had to use an explicit ... 
I mean just cast, above).

That doesn't really affect the substance of the discussion that what is 
actually passed in registers is not the value of the array elements. But 
C people are cagey about exactly how F works if it's not really by-value 
and not really by-reference.

> If your point of view is that pointers are what is "real under the
> hood", then call-by-reference is just "syntactic sugar" for pointers.

No, my point of view, first expressed on 9-Jul-24, was in response to a 
claim that everything in C was passed by value, and that was that arrays 
are passed by reference. But I left out the work 'effectively'.

Of course, everybody know that is actually the case, but everybody also 
wanted to argue otherwise.