Why do people call addresses "pointers"?

[Keith Thompson]

Will both of you please knock it off?

The OP asked:

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

(Yes, there was more context than that.) What the OP *meant* was to
ask whether an lvalue of pointer type is referred to as a "pointer",
and an rvalue of pointer type is referred to as an "address". (I
won't try to answer the question here.)

Given that meaning, and given the additional context, what the OP
wrote is, I think, a reasonable way to ask the question.

Given the way the question was phrased, it's not entirely unreasonable
to assume, mistakenly, that the OP meant that lvalues in general are
referred to as "pointers".

In fact, given a different set of terminology, that's not an entirely
unreasonable way to look at it. Given:

int foo;
foo = 42;

the expression "foo" in the assignment statement is an lvalue. You
can think of it as implicitly taking the address of foo; after all,
the machine needs to know where foo is to be able to assign a value to
it. This breaks down for two reasons: you can assign a value to a
"register" variable, which doesn't necessarily have an address, and
the C standard doesn't talk about it that way. In the abstract
machine defined by the C standard, taking the address of the target
isn't part of an assignment statement (even though it may happen on
the machine level). But you could easily define an abstract machine
in which it is, which makes it even easier to assume that that's what
the OP had in mind. I don't know (or much care) whether anyone in
this discussion thought of it that way.

This is a discussion group. Misunderstandings happen all the time.
The usual approach is to clarify what was meant and move on.

Endless cascades are frowned upon. It's usually appropriate to
provide some context, but it seldom makes sense to quote the entire
previous article.

If you want to call each other idiots, either for not writing clearly
or for not reading clearly, this is not the place for it. If you
don't want to talk about C, please talk somewhere else.

 

[Keith Thompson]

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

If you want to be strict about it, you can say that a "pointer" is an
*object* of some pointer type, and an "address" is a *value* of some
pointer type. Both objects and values have types; in both cases, the
type is a "pointer type".

Most people, though, aren't that precise -- and in this particular
case, it's not a problem. We don't generally talk about "address
objects", but we do talk about "pointer values" (which might be more
properly called "address values"). In practice, the meaning is almost
always clear from the context. Just remember that if a function is
said to expect a pointer argument, that doesn't mean the argument has
to be an objectd; it can be any address expression of an appropriate
type.

Even the standard sometimes uses "pointer" and "address" almost
interchangeably. For example, in footnote 53 (C99 6.3.2.1), it says:

As a further example, if E is a unary expression that is a pointer
to an object, *E is an lvalue that designates the object to which
E points.

It probably should refer to the expression as the address of an
object, but the meaning is clear.

In my opinion, it's not worth worrying about.

 

[j]

Will both of you please knock it off?

The OP asked:

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

(Yes, there was more context than that.) What the OP *meant* was to
ask whether an lvalue of pointer type is referred to as a "pointer",
and an rvalue of pointer type is referred to as an "address". (I
won't try to answer the question here.)

As I have stated elsewhere in the thread, don't expect people to discern
what you meant to say from what you actually said. In fact, the original
poster has already stated that the object of his second question, the
``lvalue'' was referring to his first question. However, his first question
contains no use of an lvalue. That is, an entity used to designate
an object to store some value. So it is bankrupt from the start.

Given that meaning, and given the additional context, what the OP
wrote is, I think, a reasonable way to ask the question.

I disagree. His second question, according to him, was referring back
to his initial question. So the usage of ``the lvalue'' in the second
question
to refer back to the initial question that did not contain any use of an
lvalue,
is utterly meaningless. In fact, I gave the OP the benefit of the doubt and
interpreted his second question as referring to ``lvalue the concept''.
Being that I saw no use of an lvalue in his initial question.

Given the way the question was phrased, it's not entirely unreasonable
to assume, mistakenly, that the OP meant that lvalues in general are
referred to as "pointers".

Like I said, I gave him the benefit of the doubt. His claim that his
second question involving the usage ``the lvalue'' was referring to
the first question -- which unfortunately for him, did not contain the
use of an lvalue -- is really bankrupt. That is, there was no such
expression involing the designation of an object to store some
value in.

In fact, given a different set of terminology, that's not an entirely
unreasonable way to look at it. Given:

int foo;
foo = 42;

the expression "foo" in the assignment statement is an lvalue. You
can think of it as implicitly taking the address of foo; after all,
the machine needs to know where foo is to be able to assign a value to
it. This breaks down for two reasons: you can assign a value to a
"register" variable, which doesn't necessarily have an address, and
the C standard doesn't talk about it that way. In the abstract
machine defined by the C standard, taking the address of the target
isn't part of an assignment statement (even though it may happen on
the machine level). But you could easily define an abstract machine
in which it is, which makes it even easier to assume that that's what
the OP had in mind. I don't know (or much care) whether anyone in
this discussion thought of it that way.

Good.

This is a discussion group. Misunderstandings happen all the time.
The usual approach is to clarify what was meant and move on.

I have pointed out the error. It is not difficult to comprehend.

Endless cascades are frowned upon. It's usually appropriate to
provide some context, but it seldom makes sense to quote the entire
previous article.

If you want to call each other idiots, either for not writing clearly
or for not reading clearly, this is not the place for it.

I have not called him an idiot once. I suggested that he
looks ``foolish'' for using the word ``idiot'' excessively.

And this has absolutely nothing to do with not reading clearly.
Which I have demonstrably shown elsewhere in the thread.

It has everything to do with not using an lvalue with respect
to his initial question but insisting that his second question
had some relevancy in regards to an lvalue being used in
his first question.

 

[j]

Will both of you please knock it off?

The OP asked:

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

(Yes, there was more context than that.) What the OP *meant* was to
ask whether an lvalue of pointer type is referred to as a "pointer",
and an rvalue of pointer type is referred to as an "address". (I
won't try to answer the question here.)

As I have stated elsewhere in the thread, don't expect people to discern
what you meant to say from what you actually said. In fact, the original
poster has already stated that the object of his second question, the
``lvalue'' was referring to his first question. However, his first question
contains no use of an lvalue. That is, an entity used to designate
an object to store some value. So it is bankrupt from the start.

Given that meaning, and given the additional context, what the OP
wrote is, I think, a reasonable way to ask the question.

I disagree. His second question, according to him, was referring back
to his initial question. So the usage of ``the lvalue'' in the second
question to refer back to the initial question that did not contain any
use of an lvalue, is utterly meaningless. In fact, I gave the OP the
benefit of the doubt and interpreted his second question as referring
to ``lvalue the concept''. Being that I saw no use of an lvalue in his
initial question.

Given the way the question was phrased, it's not entirely unreasonable
to assume, mistakenly, that the OP meant that lvalues in general are
referred to as "pointers".

Like I said, I gave him the benefit of the doubt. His claim that his
second question involving the usage ``the lvalue'' was referring to
the first question -- which unfortunately for him, did not contain the
use of an lvalue -- is really bankrupt. That is, there was no such
expression involing the designation of an object to store some
value in.

In fact, given a different set of terminology, that's not an entirely
unreasonable way to look at it. Given:

int foo;
foo = 42;

the expression "foo" in the assignment statement is an lvalue. You
can think of it as implicitly taking the address of foo; after all,
the machine needs to know where foo is to be able to assign a value to
it. This breaks down for two reasons: you can assign a value to a
"register" variable, which doesn't necessarily have an address, and
the C standard doesn't talk about it that way. In the abstract
machine defined by the C standard, taking the address of the target
isn't part of an assignment statement (even though it may happen on
the machine level). But you could easily define an abstract machine
in which it is, which makes it even easier to assume that that's what
the OP had in mind. I don't know (or much care) whether anyone in
this discussion thought of it that way.

Good.

This is a discussion group. Misunderstandings happen all the time.
The usual approach is to clarify what was meant and move on.

I have pointed out the error. It is not difficult to comprehend.

Endless cascades are frowned upon. It's usually appropriate to
provide some context, but it seldom makes sense to quote the entire
previous article.

If you want to call each other idiots, either for not writing clearly
or for not reading clearly, this is not the place for it.

I have not called him an idiot once. I suggested that he
looks ``foolish'' for using the word ``idiot'' excessively.

And this has absolutely nothing to do with not reading clearly.
Which I have demonstrably shown elsewhere in the thread.

It has everything to do with not using an lvalue with respect
to his initial question but insisting that his second question
had some relevancy in regards to an lvalue being used in
his first question.

 

[Kobu]

And this has absolutely nothing to do with not reading clearly.
Which I have demonstrably shown elsewhere in the thread.

It has everything to do with not using an lvalue with respect
to his initial question but insisting that his second question
had some relevancy in regards to an lvalue being used in
his first question.

I understood what the OP was asking perfectly. I guess you're the only
smart one who roams c.l.c. I don't think newbies like it when they're
told "if you don't understand, buy a book on C," especially when it was
the responder who didn't understand. I always hated those remarks!

Still, retaliating with all the "idiot" remarks wasn't exactly
respectful either.

 

[CBFalconer]

(e-mail address removed) says...


How about learning how to snip for crying out loud?

At last - a voice of sanity.

 

[john_bode]

Hi,

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

"Pointer" is a more generic term. A pointer can be an address, or an
address + an offset, or an array index, or something else entirely.
*Ususally*, pointers in C correspond to an address value, but they
don't need to.

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

I think you're conflating two different concepts. It is true that an
address expression such as &a is never an lvalue (i.e., you can't write
&a = something), whereas an indirection expression may be an lvalue (*p
= &a). Remember that an lvalue is an expression that refers to a chunk
of memory such that the memory may be read or written to, and an rvalue
is any expression that isn't an lvalue.

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

I'm not sure what you mean by "rvalues moving around in a program".
Any object that has type "pointer to T" is referred to as a pointer,
regardless of whether it's an lvalue or not.

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

Again, because a pointer isn't necessarily an address value.

 

[Joe Wright]

Hi,

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

A pointer is an object. An address is a value.
A pointer object can store the value of an address.
This address value becomes the pointer object's value.
People will use often 'pointer' and 'address' interchangeably,
but technically a function would return an 'address
value', which can be stored in a pointer type object.

-Mike

You are completely right here. Don't let anybody talk you out of it.

 

[Keith Thompson]

I'm not sure what you mean by "rvalues moving around in a program".
Any object that has type "pointer to T" is referred to as a pointer,
regardless of whether it's an lvalue or not.

The name of any object is an lvalue. (This isn't clear from the
standard's broken definition of "lvalue", but it's the intent.)

 

[Jack Klein]

AFAIK "pointer" is a logical construct, which is usually (in C) resolved
into an adress. For most C compilers the two terms are equivalent, but this
is not always the case. Specifically all kinds of segment constructions can
fuzzify the issue.

No, a pointer is an object. It can contain an address. The two terms
are not equivalent at all. Any more than double, which is an object,
is identical with a floating point value, which it can contain.

 

[Jack Klein]

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

If you want to be strict about it, you can say that a "pointer" is an
*object* of some pointer type, and an "address" is a *value* of some
pointer type. Both objects and values have types; in both cases, the
type is a "pointer type".

Most people, though, aren't that precise -- and in this particular
case, it's not a problem. We don't generally talk about "address
objects", but we do talk about "pointer values" (which might be more
properly called "address values"). In practice, the meaning is almost
always clear from the context. Just remember that if a function is
said to expect a pointer argument, that doesn't mean the argument has
to be an objectd; it can be any address expression of an appropriate
type.

Even the standard sometimes uses "pointer" and "address" almost
interchangeably. For example, in footnote 53 (C99 6.3.2.1), it says:

As a further example, if E is a unary expression that is a pointer
to an object, *E is an lvalue that designates the object to which
E points.

It probably should refer to the expression as the address of an
object, but the meaning is clear.

Actually, no, the wording of the footnote is exactly correct.

Paragraph 3 of 6.5.3.2 Address and indirection operators:

"3 The unary & operator returns the address of its operand. If the
operand has type ‘‘type’’, the result has type ‘‘pointer to type’’."

An "address" is not a defined type in C, it is a sort of "magic
cookie". Nowhere in the standard is the term "address" defined. An
address is only accessed by use of the '&' (address) operator, but
that operator yields a pointer that somehow relates to the "magic
cookie" of the address itself.

The only information the standard actually provides about this
mysterious address is that every function and every object not defined
with register storage type has one.

You can't do anything with an address other than create a pointer.
Addresses are not visible to a C program, only pointers created by
taking an address.

It's a subtle distinction.

 

[infobahn]

Hi,

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

A pointer is an object.

Is NULL a pointer? Is it an object?

Given: char *p = "foo"; is p + 3 a pointer? Is it an object?

Is strcmp a pointer? Is it an object?

 

[jcoffin]

infobahn wrote:

[ ... ]

Is NULL a pointer? Is it an object?

NULL is a macro that expands to 0 in some implementation-defined
fashion -- it will usually 0, or 0L, or ((void *)0), but in some
particularly perverse implementation, could be something stupid like
('2' - ('1' + '1')). In any case, it has to be an integer constant
expression with the value 0.

Given: char *p = "foo"; is p + 3 a pointer? Is it an object?

'p+3' is the address of a NUL byte. It is not an object, but it is a
value that could be assigned to an object.

Is strcmp a pointer? Is it an object?

The standard library contains a function named strcmp, and could
conceivably contain a macro by the same name as well. If 'strcmp' is
evaluated in a program (by itself) it will evaluate to the address of
that function. A function is not an object, but (like the address
above) the address of a function is a value that could be assigned to
an object of the correct type (the correct type in this case being
"pointer to function").

 

[infobahn]

infobahn wrote:

[ ... ]

Is NULL a pointer? Is it an object?

NULL is a macro that expands to 0 in some implementation-defined
fashion -- it will usually 0, or 0L, or ((void *)0), but in some
particularly perverse implementation, could be something stupid like
('2' - ('1' + '1')). In any case, it has to be an integer constant
expression with the value 0.

I presume you agree that NULL is not an object, then. Now let's
look at the Standard.

Firstly, NULL (a little whitespace has been elided):

The macros are NULL which expands to an implementation-defined null
pointer constant"

Okay, now "null pointer constant":

"An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant."

If NULL is not a pointer, then a null pointer constant is not a pointer.
Weird.

So either the claim that a pointer is an object is false, or NULL
is an object, or a null pointer constant is not a pointer.

Which of the three do you consider most likely?

 

[Mike Wahler]

Hi,

I'm just wondering why people/books/experts say "the function returns a
pointer to.." or "we have to send scanf a pointer to.." instead of "the
function returns the address of.." or "we have to send scanf the
address of.."

Isn't the lvalue called a POINTER TO and the (r)value called the
ADDRESS OF?

Why do people refer to the (r)values moving around in a program as
pointers? (Am I missing something, or just reading too much into a
non-issue?)

[I've noticed that experts almost never say "address of", but often
time beginners do... there must be something to it]

A pointer is an object.

Is NULL a pointer? Is it an object?

Neither. It's the null pointer constant, specifically defined
by the langauge standard.

Given: char *p = "foo"; is p + 3 a pointer? Is it an object?

Neither. It's an expression whose value is an address.
The expression has a pointer type.

Is strcmp a pointer? Is it an object?

Neither. It's a function.

-Mike

 

[Mike Wahler]

infobahn wrote:

[ ... ]

Is NULL a pointer? Is it an object?

NULL is a macro that expands to 0 in some implementation-defined
fashion -- it will usually 0, or 0L, or ((void *)0), but in some
particularly perverse implementation, could be something stupid like
('2' - ('1' + '1')). In any case, it has to be an integer constant
expression with the value 0.

I presume you agree that NULL is not an object, then. Now let's
look at the Standard.

Firstly, NULL (a little whitespace has been elided):

The macros are NULL which expands to an implementation-defined null
pointer constant"

Okay, now "null pointer constant":

"An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant."

If NULL is not a pointer, then a null pointer constant is not a pointer.
Weird.

Not at all. A constant is not an object. However an
object can store the value of a constant.

So either the claim that a pointer is an object is false, or NULL
is an object, or a null pointer constant is not a pointer.

Which of the three do you consider most likely?

The third (not just likely, but a fact).

-Mike

 

[Chris Torek]

... "null pointer constant":

"An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant."

If NULL is not a pointer, then a null pointer constant is not a pointer.
Weird.

Indeed, one of the two valid forms of null pointer constant is not
a pointer (or more precisely, not "a value of type pointer to T,
for some valid type T"). Instead, it is a value of some integral
type -- most likely "int", but perhaps "long" or similar. (Its
value is zero, or more precisely, "an int 0" or "a long 0" or
whatever.) The other form is -- it is a value of type "pointer to
void". (Its value is hard to describe, other than using the rather
vague / self-referential phrase, "a null pointer". All that the
C standard says about it is that it will compare unequal to the
address of any object or function, after appropriate type-conversions.
If the linker computes "&__impl_unused_byte" at link time, and
fills that in -- with any conversions required as well, of course
-- for all the null pointers, the actual machine-level address used
for NULL will depend on where that byte winds up in the executable!
This is quite different from the usual concrete implementation, in
which "machine address 0" or "machine address -1" is used.)

This is particularly confusing when the null pointer constant is
not a pointer at all, but is used to create null pointers:

int *p = 0;

sets p to whatever value is used for "null of type pointer to int"
(despite the lack of a cast).

Note also that there is nothing forcing an implementation to use only
one single "null pointer": the "null of type pointer to int" machine-
level address might be &__impl_null_int, while the "null of type
pointer to char" machine-level address might be &__impl_null_char.
An implementation that did this would, however, probably have to
do something to make:

char *q = (char *)p;
if (q == NULL) ...

"work right". (I think that the C standard claims that all null
pointers compare equal, when suitably converted, but I would have to
double-check, and it is late... )

 

[Keith Thompson]

Okay, now "null pointer constant":

"An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant."

If NULL is not a pointer, then a null pointer constant is not a pointer.
Weird.

A null pointer constant is not a pointer; it's a source code construct.
Pointers exist only during program execution.

 

[infobahn]

A null pointer constant is not a pointer; it's a source code construct.
Pointers exist only during program execution.

Okay, let's try another tack.

The Standard says: "The result of the unary & (address-of) operator
is a pointer to the object or function designated by its operand."

So &object is a pointer. Is it your contention that &object is
itself an object?

 

[Keith Thompson]

Okay, let's try another tack.

The Standard says: "The result of the unary & (address-of) operator
is a pointer to the object or function designated by its operand."

So &object is a pointer. Is it your contention that &object is
itself an object?

Certainly not.

That wording is from the C90 standard. C99 6.5.3.2p3 says:
"The unary & operator returns the address of its operand."

In my opinion, the wording in the C90 standard was imprecise, and the
C99 wording is an improvement.