From: ted.jensen@spacebbs.com (Ted Jensen) 
Newsgroups: comp.lang.c
Subject: Re: Pointer/address reluctance
Date: 22 Aug 92 14:47:00 GMT
Distribution: na
Organization: SPACE BBS - Menlo Park, CA - 10 Lines + 4gB - 415-323-4193
Reply-To: ted.jensen@spacebbs.com (Ted Jensen) 


While I did not see the original post, I have followed the last
half dozen or so comments in this thread and would like to
state that I have been frustrated with the insistence on many
writers (including K&R) to refer to an address as a pointer.
IMHO, I find it much easier to think of an address as a value
which identifies a location in memory, and a pointer as a
variable designed to hold a value which identifies a location in
memory, i.e. an address.

Based on the above definitions (which I feel few could argue
with), a pointer is an lvalue whereas an address is not.  Thus,
there is a distinct difference between the two.  What is
frustrating is when a writer states that a function or
calculation "returns a pointer".

The problem, of course, stems from the failure to distinguish
between an integer variable, and an integer value, a float
variable and a float value, etc.  Consider the following:

int j,k;

const int m = 23;

j = 12;

k = 17 * j;

Both j and k are integer variables.  Space has been reserved in
the data area for storage of these variables and the address of
this space can be obtained using &j or &k respectively.  The
contents of each of these respective memory locations are subject
to change during the course of the program, hence the use of the
term "variable".

Now, space has also been reserved in memory to hold the value of
the constant m.  It is expected that this value will not change
throughout the life of the program but will be available to any
number of places throughout the program (if visible).

Now, looking at the "17" in the statement that follows the
variable definitions, we note that it represents a specific
integer value.  In this case, it is also an integer constant (i.e.
unchanging throughout the life of the program).  However, it is
not stored in the data space, it is "hard-wired" into the code
space itself.  Most, however, would simply refer to 17 as an
integer (changing from the semantics of C to the semantics of
mathematics without a second thought).

But what of the value returned by the multiplication of the 17
times the current value of j?  This value is 204.  While this
value may at some point in the actual running of the program end
up being stored on the stack or in a register within the CPU, it
has no "address" in the data space (excluding the stack) which
can be retrieved through the use of the & operator.

Is it an integer variable?  (it may not be constant throughout
the life of the program since it is dependent on the value of j).
Is it an "object"?  Is it an integer constant?  In short, while
we can correctly state that it is of "type" integer I find it
difficult to come up with words which would better define it,
with the possible exception of "integer value".

The same arguments could, of course, be made for a double, a
float, or a character.

Keeping all of the above in mind we now come to the question at
hand.  Is there a difference between a pointer and an address?
As I stated in my opening argument, unless specifically stated I
think of a pointer as a variable occupying space in the data
space of memory and designed to hold an address.  Thus, unless we
are talking about a pointer constant, a pointer is an lvalue and
an address is not.

Whenever I see something like:

  int *ptr;
  int array[25];

  ptr = array;

and the writer writes something like:  "The reason we can do this
is that the name of an array returns a pointer."  it effects me
in the same manner as fingernails on chalk board!  Using
"..returns a pointer constant" is a little better,  but what is
wrong with  "... returns the address of the first element in the
array." ???

"array" is not a pointer, it is an address!  (IMHO!)

Similarly, I think of functions as returning addresses, not
pointers, and calls to them as passing addresses, not pointers.
>>> Continued to next message
---
 * SLMR 2.0 * 
                                              
Newsgroups: comp.lang.c