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

On 7/6/2024 5:38 PM, Keith Thompson wrote:

BGB <cr88192@gmail.com> writes:

On 7/6/2024 2:23 AM, Lawrence D'Oliveiro wrote:

On Fri, 05 Jul 2024 11:46:38 -0700, Keith Thompson wrote:
>

No, arrays are not pointers.

Except array indexing is designed to be indistinguishable from
pointer
arithmetic.

>
Yeah, and in the 1D case, an array can be seen as functionally an
implicitly defined pointer with an assigned size and preassigned
backing memory.

 No, there is no implicitly defined pointer.
 Consider:
      int integer_object;
     int array_object[10];
 This create an object of integer type with size sizeof(int) and an
object of array type with size 10 * sizeof (int).  There is no implicit
pointer object associated with it either of them.
 If you evaluate the expression `array_object` in most contexts, it's
implicitly converted to a pointer *value*, pointing to the 0th element
of the array object.  There is still no implicit pointer object.
Similarly, evaluating `&integer_object` yields a pointer value, but does
not allocate a pointer object (but the "&" operator has to be explicit).
 In very early C, before K&R1, an array object declaration actually did
implicitly create a pointer object holding the address of its initial
element.  This became unworkable for structs containing members of
struct type; copying a struct would copy the address of the array but
not the array itself, resulting in the two structs sharing the same
array data.
 

This implicit pointer need not exist at a location in memory...
In my compiler, such implicit pointers do exist in the stack frame though, and are used in some cases (such as when the backing memory is located on the heap rather than in the stack frame; which is also a feature in my compiler).
But, yeah, putting implicit pointers to struct arrays within structs would likely be unworkable...
I am not really in favor of "exposing" their existence in the language proper, as this would open up a whole mess of meta-issues (so, whether or not every array and struct also has a transient pointer holding its address, or one that pops into existence whenever one tries to access an array within a structure, ..., can be left as a matter of interpretation...).

Granted, C generally allows one to see the backing memory, but not the
implicit pointer to said backing memory. I guess one could argue that
if one can't take the address of it, it doesn't exist, but yeah...
>
Kind of a similar feature with lvalue structs:
   An implicit pointer exists...
   But, C wont let you see it directly or take its address.

 If you take the address of a struct object, you get a pointer *value*.
There is no implicit pointer *object*, so there's nothing whose address
can be taken.
 

Well, unless it exists in the compiler and ABI (which, in my compiler, is actually the case).
But, either way, probably still don't want code taking the address of it (and there is no defined way to do so within C).

If you assume that arrays are really pointers, it's difficult or
impossible to build a consistent model of how C works.  If instead you
realize that arrays are arrays and arrays are pointers, and that C has
some peculiar rules about their interaction, everything is peculiar but
consistent.
 

Well, as noted, I am thinking some here more at the level of compiler implementation, not necessarily at the level of C language semantics.
The language semantics and compiler/ABI behavior need not be strictly 1:1 in these areas.
Like, say, if one has an implementation where the whole existence of things like passing structures by value is, in effect, an illusion...
But, to some extent, the existence of local variables as singular entities holding a value of a specific size in a specific location, is itself also an illusion (as they may or may not have a location on the stack, or have their existence hop around from register to register based on whichever register happened to be available at the moment, and only appearing in memory at the time one takes its address, ...).

[...]