Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?UTF-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Wed, 10 Jul 2024 06:05:14 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <20240709225811.135@kylheku.com>
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> <v6l2o7$1p1a5$2@dont-email.me>
 <v6l5r7$1pcjr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Jul 2024 08:05:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7b522d35a8b6a4705d66078d67bdff1e";
	logging-data="1894584"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+qFO0ltYAReZB1v+a+CJDOAe1+j4vvhI4="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:+pdoE4pbvJgMqhmy8OVnMWRMiEc=
Bytes: 3290

On 2024-07-10, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 7/10/24 00:29, Lawrence D'Oliveiro wrote:
>> On Sat, 06 Jul 2024 15:38:14 -0700, Keith Thompson wrote:
> ...
>>> 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.
>> 
>> The OP said “pointer”, not “pointer object” or “pointer value”. Not sure 
>> what hair you are trying to split here.
>
> BGB referred to it as an "implicitly declared" pointer. You can declare
> objects in C, but not values. An object has a location in addressable
> memory where it is stored, a value need not exist anywhere in
> addressable memory.

Right. But language features can use hidden variables.

> In every implementation that I'm sufficiently familiar with, no memory
> is set aside to store such a pointer object.

Even if the high level code generation declares such a hidden
variable, as in

  int a[42];
  int *$_ptr_a = a; // generated by compiler
                    // perhaps as an AST node rather than source

it could end up optimized away, like any other variable. Since the
variable is not visible to the program, no assignment to its value
will occur (unless the generated code does that). If no assignment
to it occurs, the optimization can just treat it as an alias for a,
and substitute every occurrence of $_ptr_a with a. (Raising the
question why the code generator didn't do that itself; it could
be a remnant from an ancient verson of the compiler that wasn't well
optimized. Then the optimizer came along, taking away the motivation
to fix something in the front that is taken care of by it.)

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca