Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need a "new" C ? Date: Sat, 06 Jul 2024 15:38:14 -0700 Organization: None to speak of Lines: 60 Message-ID: <87h6d2uox5.fsf@nosuchdomain.example.com> References: <871q48w98e.fsf@nosuchdomain.example.com> <87wmlzvfqp.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 07 Jul 2024 00:38:14 +0200 (CEST) Injection-Info: dont-email.me; posting-host="31bef4326a7de5d231f958bc2ab73da5"; logging-data="4185240"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18o13go0VblNS5PdRduiMgC" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:wRp0jSLY77iBzONs7gW2lodqC6k= sha1:iE2EjyzbHACEhHKlLnJ23aGKmSQ= Xref: csiph.com comp.lang.c:386826 BGB 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. > 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. 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. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */