Re: Threads across programming languages

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> 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.