Re: Threads across programming languages

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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.

That's obvious (and a bit condescending).

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.

Obviously, and I can't figure out why you feel the need to make that
point.  Of course the phrase "pointer object" doesn't mean "pointer
value".  I didn't suggest that it could, or that anyone might think it
could.

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 terms "pointer object" and "pointer value" are unambiguous, are they
not?  Using "pointer value" rather than "pointer" is more precise than
the standard's typical usage, but does not conflict with it.

I haven't bothered to search the standard for all uses of the word
"pointer", and I'm not planning to do so.  Apparently it's reasonably
consistent in its usage, and does not refer to objects of pointer type
as "pointers".  Rather a "pointer" is either a pointer type or an object
of pointer type, and I presume each using is clear enough in context.

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.

Sure.

Incidentally, the footnote you cited refers to an *expression* as "a
pointer".  I'm not sure that supports your point.  I can accept that the
usage in that footnote is informal.

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.

It would deserve to be called out if anyone actually suggested it.
I certainly did not.

The idea that a pointer object is a pointer "rather than an object" is
obviously wrong, and not something I suggested.  Of course a pointer
object (an object of pointer type) is an object, as I've already
explicitly said.  My suggestion was that an object of pointer type might
be informally referred to as "a pointer".  Perhaps the standard never
does so.

I get the impression that you're assuming that the word "pointer" can
*never* refer to an object of pointer type, and that clarifying the
distinction is therefore a waste of time.  Is that accurate?

I note that
<https://en.wikipedia.org/wiki/Pointer_(computer_programming)> says:

In computer science, a pointer is an object in many programming
languages that stores a memory address.

which suggests that your statement that "a pointer is not an object"
might call for some clarification, even if it's entirely consistent with
the usage in the C standard.

I'm not presenting that sentence from Wikipedia as correct.  I'm using
it to suggest that informally referring to a pointer object as "a
pointer" is common enough that it's worth mentioning the potential
ambiguity.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */