Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Threads across programming languages Date: Thu, 23 May 2024 08:54:35 -0700 Organization: A noiseless patient Spider Lines: 76 Message-ID: <86v834v804.fsf@linuxsc.com> References: <20240503180102.00002f98@yahoo.com> <86zfsnqhn6.fsf@linuxsc.com> <87fruely54.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 23 May 2024 17:54:37 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e3ccaa8757308aabad5512a33960ab38"; logging-data="1927551"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dr1+QRDU/93efOoF4JnJuEVgjv58gfrI=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:uTPcTgwk6JxnA9odvpGOcelN060= sha1:2W7P9Ki+95xldsuuv4YGfl5iB3o= Bytes: 5507 Keith Thompson writes: > Tim Rentsch writes: > [...] > >> First, a pointer is not an object. In both C and C++, any pointer, >> including a function pointer, is a scalar value. A pointer value >> might be held in an object but it doesn't have to be. In most cases >> function pointers are not stored in objects but simply used to call >> the function pointed to. > > [...] > > Certainly a pointer value is not an object. Certainly a pointer > object *is* an object. It's not uncommon to informally refer to a > pointer object as "a pointer". I presume you would consider such > usage to be incorrect, and I don't disagree, but it is fairly > common. Good usage will be precise and logically consistent, adhere to the rules of normal English usage, and align with how terminology and phrasing is used in the C standard. On the flip side, it is best to try to avoid phrasing that is haphazard, careless, confusing, or sloppy. I don't remember ever seeing the phrase "pointer object" used to mean a pointer value, either informally or otherwise. The C standard does use the phrase "pointer object" in some places, but it means something quite different from a pointer, namely, an object that has pointer type (and not a pointer itself). A local declaration such as int *p; introduces the identifier 'p' as (a way to designate) a pointer object, but there is no pointer value anywhere in sight. > I often find it useful to avoid referring to "pointers", and > instead refer to "pointer types", "pointer values", "pointer > objects", and so on (likewise for arrays). I have the impression that you are someone who is unusually averse to ambiguity. I appreciate that your suggestions are given with the idea that they will help with clarity of communication. Unfortunately they don't always help, and sometimes make things worse rather than better. Your comment here is a case in point. The C standard uses the word pointer (or pointers) in a little over 900 places. In most of those, pointer is used as a simple noun; whether in each case it refers to a type or a run-time value is clear from context. Notably, the C standard uses the phrase "pointer value" in just a few places (I see five in n1570). It seems clear that the Standard's use of this phrase is meant to connote something different than just "pointer" by itself, and also that this (rather rare) usage wasn't chosen by accident. So the rule you describe muddies the water rather than helping, because it's not consistent with usage followed in the C standard. > The C standard does not, as far as I can tell, provide a > definition for the standalone term "pointer". (I could have > missed something; I checked section 3, "Terms, definitions, and > symbols", and the index.) But the standard does, in several > places, use the term "pointer" to refer to a pointer value. I > don't know whether it's consistent. Yes, AFAICT the C standard doesn't define "pointer" as a standalone noun. But it is clear from context that "pointer" by itself means basically the same thing as an address, as can be seen from the description of unary &, in 6.5.3.2 p3, or in the second sentence of the second paragraph of the footnote to 6.3.2.1 p1. The C standard does, however, define the word "object" to mean a region of storage in the execution environment. Whatever it is that a pointer might be, it's clear that it isn't a region of storage in the execution environment. The idea that a pointer object might be a pointer, rather than an object, is nonsensical on its face, and deserves to be called out as such.