Re: technology discussion → does the world need a "new" C ?

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