Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.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: Sun, 7 Jul 2024 22:10:48 -0500
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <v6fle4$n269$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <871q48w98e.fsf@nosuchdomain.example.com>
 <v68dsm$37sg2$1@dont-email.me> <87wmlzvfqp.fsf@nosuchdomain.example.com>
 <v6ard1$3ngh6$4@dont-email.me> <v6b0jv$3nnt6$1@dont-email.me>
 <87h6d2uox5.fsf@nosuchdomain.example.com> <v6d779$6rk5$2@dont-email.me>
 <v6e76u$c0i9$1@dont-email.me> <v6esqm$fian$2@dont-email.me>
 <v6f7vg$hgam$1@dont-email.me> <20240707164747.258@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 08 Jul 2024 05:12:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cd76dc2001c036cabec0a5093b6250d9";
	logging-data="755913"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Fvxiedtm34XbMtPr465YsOl4ZYCRt2dM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dPJWENxgAF6fYdFQojJ/KND+8Hw=
In-Reply-To: <20240707164747.258@kylheku.com>
Content-Language: en-US
Bytes: 4976

On 7/7/2024 7:02 PM, Kaz Kylheku wrote:
> On 2024-07-07, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 7/7/24 16:10, BGB wrote:
>>> On 7/7/2024 9:03 AM, James Kuyper wrote:
>>>> On 7/7/24 00:55, BGB wrote:
>>>>> On 7/6/2024 5:38 PM, Keith Thompson wrote:
>>>> ...
>>>>>> No, there is no implicitly defined pointer.
>>>> ...
>>>>> This implicit pointer need not exist at a location in memory...
>>>>
>>>> Which is why C doesn't give you access to it's location in memory -
>>>> something you complained about earlier.
>>>
>>> I don't think I was claiming that one should have direct access to its
>>> location or value within the language, rather that their existence and
>>> behaviors could be acknowledged in the language design (for a "not
>>> quite C" language).
>>
>> I think that the existence of an implicit pointer would be a bad thing
>> to acknowledge, given that the language doesn't require that it exist,
>> and typical implementations don't use them. From what I understand, the
>> fact that your implementation does have implicit pointers makes it a rarity.
> 
> Ritchie's B language had arrays which contained a pointer to their
> first element. Via a hack, it was possible to relocate an array.
> 
> In C, such a thing is not simply not required; it is ruled out
> by the detailed semantic description of arrays.
> 
> The entire representation of an array of size N elements of type
> T is contained in the memory block that is sizeo(T)*N bytes wide.
> 
> If you copy that block, you have a fully functional copy of the array.
> No extra pointer needs to be set up with the correct value.
> 
> Furthermore, to dynamically allocate an array, you need only
> provide sizeof(T)*N bytes of storage, and not a bit more.
> 
> There is simply nowhere in the representation of an array where
> a pointer could hide that is part of the representation.
> 

All this only really applies if one assumes the pointer to the array is 
part of the array itself.

In the case of the "hidden pointer", it does not exist within the array 
or object data, but rather, at another location within the function's 
stack frame and/or held in a register, and its existence is mostly 
invisible.

Implicitly, the value of this pointer can be exposed when an array 
decays into a pointer (or when taking the address of a struct).


> Code that manipulates arrays can be translated into something that
> calculates a pointer. So a pointer can exist at run time, in a transient
> way, perhaps in a register. That register can even be spilled into
> memory. However, that's just part of the state of an evolving
> calculation, not part of the representation of the array.
> 

I was never saying the pointer is *in* the array or object...


But, yeah, they generally exist on the stack or in registers, sometimes 
coming into existence as part of another calculation.

But, in any case, there often needs to be "something" to keep track of 
the address.

Much like, if one writes:
   y=3*x+4;
And it becomes, internally, say:
   _T0=3*x;
   y=_T0+4;


There are hidden temporary variables holding the intermediate results of 
the calculation, which may potentially also exist in the stack frame in 
some cases (but, within C, there isn't really a way to observe them 
directly nor to take their address; nor would one necessarily want it to 
be possible to do so).

....