Good Tutorials

N

Nick Keighley

Um, how is it wrong?

A pointer is an address; the way the standard defines the terms,
they're nearly synonymous (though I suspect Richard is using the term
"address" in some more hardware-specific way).  And it's always
possible to represent a pointer value / address in hexadecimal; even
if "%p" doesn't do this, you can interpret its representation as an
array of unsigned char.

An address is not a number (though it's often implemented that way),
but Richard didn't make that particular claim here.

yes. I meant "a pointer is not a number" rather than "a pointer
is not an address". I interpreted "it's always possible to represent
a pointer value / address in hexadecimal" as "a pointer is a number".
 
R

Richard

Nick Keighley said:
yes. I meant "a pointer is not a number" rather than "a pointer
is not an address". I interpreted "it's always possible to represent
a pointer value / address in hexadecimal" as "a pointer is a number".

So where was I wrong?

And and address on MOST platforms IS represented as a number ....

This whole issue is somewhat silly.
 
B

Ben Bacarisse

Richard said:
So where was I wrong?

Where you claimed that there was a 'constant desire to confuse people
with a "pointer is not an address"'. That claim is never made by
knowledgeable posters and I have seem Keith Thompson correct it a
couple of time when it is made by people who are obviously already
confused. Nobody that you would call a "reg" makes it and none of
them have a desire to confuse people by introducing such a falsehood.
And and address on MOST platforms IS represented as a number ....

Stick with that and I doubt there will be much dissent.
 
S

soscpd

Hello Richard, James, List

soscpd said:
A teacher should never try to tell the whole truth (because there isn't
time

And, maybe: "..., neither whole truth..." :)


soscpd wrote:
Technical jargon serves many purposes, including the ignoble purpose of
separating the in-group and the out-group. However, it's main purpose is
to clearly communicate complex concepts ...

Yes indeed.
I suspect that you actually understand the difference those words

Yes, I did.
describe; I just think you're unclear about the fact that those words
describe that difference.

Hey... I did understand that too.
The difference is that a pointer object is a piece of memory

Here is, probably, my real problem. As far as my knowledge can lead
me, a pointer is an address to the beginning of a memory location.
That, in my words, make the pointer to not be ever a value. Knowing
the correct address (same to say - having the correct pointer), I can
explore (I know, with undefined consequences) any "in memory" value/
object/whatever.

Due to optimization, that pointer value might never be stored anywhere -
p+3 might be combined with some other operation, as in (p+3)->count.

Hey... "anywhere" is one of the powerful stuff about pointers.
That C code might be translated into machine code which retrieves the
byte address stored in p, and then adds to it, in a single instruction,
the combined values of 3*sizeof *p and the offset of the 'count' member
within the struct pointed at by p.
Ok.

The distinction between a pointer object and a pointer value is
....
Ok... taking the words object and value, a pointer object is the
pointer itself. Pointer value is the (address - beginning of the)
memory location who the pointer point's to. You will, then, use the
memory contents from pointer address to sizeof pointer type * n (where
n should be unsigned int > 0). If not... how can a void type ever
exists?

I mean... the only possible value of a pointer is a memory location,
right? The memory content's and how to handle it should be another
subject, IMHO.



Thanks
Rafael
 
J

James Kuyper

soscpd said:
Hello Richard, James, List ....

Here is, probably, my real problem. As far as my knowledge can lead
me, a pointer is an address to the beginning of a memory location.

A pointer value is the memory location itself. A pointer value can be
represented in a pointer object by the machine address of that location.
That, in my words, make the pointer to not be ever a value.

I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3. The contents of the
object, on the other hand, are concrete things like bits which are
either turned on or off, in a pattern which represents the value. This
is precisely the same relationship that exists between the value of a
pointer and the bit pattern that ist stored in a pointer object.
... Knowing
the correct address (same to say - having the correct pointer), I can
explore (I know, with undefined consequences) any "in memory" value/
object/whatever.



Hey... "anywhere" is one of the powerful stuff about pointers.

Yes, and despite the power of pointers, no pointer can point at the
location where the value of p+3 is stored, during the evaluation of
(p+3)->count.
 
B

Bartc

I mean... the only possible value of a pointer is a memory location,
right? The memory content's and how to handle it should be another
subject, IMHO.

A pointer can have a whole bunch of values that are not memory locations.

Maybe the memory simply doesn't exist. Or is outside an allowed range. Or
the value might be valid for one type of target but not for another (for
example a pointer to a word might require an 'even' pointer value, or the
targets exist in different memory spaces).

And sometimes, you might have different pointer values addressing the same
memory location.
 
S

soscpd

Hello James, Bartc, List

A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3.

The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case). It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).


A pointer can have a whole bunch of values that are not memory locations.

Yes... that is exactly the thing I can't figure. Isn't the point a
address to the value? Or is the pointer the value itself?

Maybe the memory simply doesn't exist. Or is outside an allowed range.

Please, define allowed. You mean, allowed for defined behavior?

the value might be valid for one type of target but not for another

Agreed. But that is not part of the (pointer) subject, IMHO.


Why we need to mix the pointer with the memory contents the pointer
point's to? There are too many possible values. Maybe understanding
pointers just as the address to memory locations will make our lifes
easy.

Through pointers, we can:
Reserve/Release some reserved memory(malloc & cia);
Point to some memory location (doesn't matter what is inside, except
if yu will use it);
Get whatever from reserved space (so, read memory from pointer to
sizeof(data));
Assign whatever to reserved space (or not reserved space - UB);
....

I just don't know if it is true (by the book. Using it just like that
works very fine... so far :).

Regards
Rafael
 
R

Richard Bos

soscpd said:
My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

Not necessarily. First, "address" can mean a lot more than just "index
into one giant pool of memory". And then a pointer is allowed to hold
more information than just the address itself. It can hold the size of
the memory block, to detect memory overflow, in debugging
implementations. Or it can hold the type of the object pointed at. That
needs a bit of fiddling with void *s, but it's possible.

Richard
 
C

CBFalconer

soscpd said:
.... snip ...

Here is, probably, my real problem. As far as my knowledge can
lead me, a pointer is an address to the beginning of a memory
location. That, in my words, make the pointer to not be ever a
value. Knowing the correct address (same to say - having the
correct pointer), I can explore (I know, with undefined
consequences) any "in memory" value/ object/whatever.

No you can't. If you try to 'explore' beyond the bounds of the
object the pointer originally pointed to, or within, the result is
undefined behaviour. Any defined action is system specific.
 
K

Keith Thompson

soscpd said:
Hello James, Bartc, List



My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?


The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case). It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).
[...]

The word "pointer", by itself, is ambiguous; it can refer either to a
pointer object or a pointer value. A pointer value is also called an
"address". (Well, mostly, I'm not sure that a null pointer value or
an indeterminate pointer value is an "address".)

You can also have a pointer type, such as int*.

To understand the distinction, let's look at integers. Again, the
word "integer" by itself could mean either an integer object, or an
integer value, or maybe an integer type. Concretely:

int x = 42;

x is an integer object. 42 is an integer value. int is an integer
type (one of several defined by the language). These are closely
related: int is the type of the integer object x, and of the integer
value 42, and 42 is the current value of the integer object x. An
integer *value* can be either the current value of an integer object,
or the result of evaluating an integer expression; the latter isn't
necessarily stored anywhere. If the value 42 is stored somewhere, it
will be represented as a sequence of bits, something like
0000000000101010 (assuming 16-bit ints).

It's the same thing with pointers:

int *p = &x; /* see above for the declaration of x */

p is a pointer object. &x is a pointer value (an address). int* is a
pointer type. int* is the type of the pointer object p, and of the
pointer value &x, and &x is the current value of the pointer object p.
Note that, unlike with integers, we don't have a literal notation for
pointer values, other than the special case of a null pointer
constant; I use the expression &x as a stand-in for that particular
value. (If you print the value using printf's "%p" format, you might
get something like "0x12345678", or "1234:5678", or "a suffusion of
yellow"; the latter is highly unlikely but not forbidden by the
standard. This is a printed representation of the pointer value; it
is not the pointer value itself.) If the value we're referring to as
``&x'' is stored somewhere, it will be represented as a sequence of
bits; the way it's represented is entirely system-specific. The
standard imposes some requirements on how integers are represented;
there are no such requirements for pointers.

And like any other value in C, a pointer value has a type as well as
just a raw value. The value that results from evaluating the
expression ``42'' has type int, and thus is distinct from the value
that results from evaluating the expression ``42.0'', which has type
double. Similarly, the value of ``&x'' is of type int*; it's not
*just* a machine address, it's an address with a particular type. The
value of ``(void*)&x'', though it refers to the same machine address,
has a different type. The type information isn't stored in memory
during program execution, it's tracked by the compiler during
compilation.
 
J

jameskuyper

soscpd said:
Hello James, Bartc, List



My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

A pointer object is a piece of memory that contains the address. The
pointer value is the location identified by that address. The term
"the pointer" could refer to either the pointer object or the pointer
value, but neither one is actually the address.
The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case).

I was talking about "an object" in general, not specifically a pointer
object. I then moved to the example of an object with a value of '3',
which would necessarily be an object of numeric type, using it as an
analogy to show what the general relationship is between an object's
representation and an object's value. I guess I didn't make the fact
that I was making an analogy very clear.
... It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).

The value of a pointer object is the memory location of another
object. That other object can also have a value. I think you're
confusing the two values. If not, you're simply confusing me :)
Please, define allowed. You mean, allowed for defined behavior?

Well, yes, accessing such a pointer object's value has undefined
behavior, but that's not what he's referring to. Some bit patterns
represent valid locations, others do not. It's possible to create a
pointer object containing such an invalid bit pattern (an
uninitialized pointer object, a pointer object used to point at an
object whose lifetime has since ended, a FILE* object that used to
identify a stream that has since been fclose()d, type punning, etc.).
In all cases, such code is described by the standard as creating an
object with an indeterminate value. Such code has undefined behavior
if any attempt is made to use the value of such a pointer object.
Agreed. But that is not part of the (pointer) subject, IMHO.


Why we need to mix the pointer with the memory contents the pointer
point's to? There are too many possible values. Maybe understanding
pointers just as the address to memory locations will make our lifes
easy.

We don't need to mix them, we need to separate them and connect them.
Without clearly distinguishing between the representation and the
value of a pointer, and the representation and value of the thing it
points at, you can't make anyone's life easier, you're just going to
create confusion.
Through pointers, we can:
Reserve/Release some reserved memory(malloc & cia);

It's the function call that reserves or releases it; the pointer just
identifies where the location that has been reserved is.
 
R

Richard

A pointer object is a piece of memory that contains the address. The

Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.
 
J

jameskuyper

Richard said:
Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.

If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.

It's reasonable to discuss the as-if rule, and to point out particular
examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if
rule. Such a description would necessarily be either too vague or too
complicated to be useful.
 
R

Richard

If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.

Thats a lot of wind for "the compiler hides the real implementation".
It's reasonable to discuss the as-if rule, and to point out particular

Yes it is. In the same its "reasonable" to say a pointer is a numeric
address of an object in memory.

However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.
examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if

Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?
rule. Such a description would necessarily be either too vague or too
complicated to be useful.

Err, yes. I think....
 
K

Keith Thompson

A pointer object is a piece of memory that contains the address. The
pointer value is the location identified by that address. The term
"the pointer" could refer to either the pointer object or the pointer
value, but neither one is actually the address.

Not quite. The way the standard uses the word "address", a pointer
value *is* an address (at least if it actually points to an object or
function).

[snip]
 
K

Keith Thompson

Richard said:
Thats a lot of wind for "the compiler hides the real implementation".


Yes it is. In the same its "reasonable" to say a pointer is a numeric
address of an object in memory.

However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.

No, he said that a pointer *object* is a piece of memory. The phrase
"a pointer" could mean either a pointer object or a pointer value,
i.e., an address.

And you're right, a pointer object isn't necessarily stored in
memory. The standard's definition of "object" is a "region of data
storage in the execution environment, the contents of which can
represent values". The phrase "region of data storage" can refer
either to memory or to one or more registers.

For that matter, the standard doesn't define the word "memory". One
*could* argue that a register is a kind of "memory", but the standard
does *use* the word memory in a way that makes it clear that registers
and memory are two different things. (Though there are CPUs on which
the registers are, or at least can be addressed as if they were, part
of main memory.)

Revised statement: A pointer object is a region of data storage that
can contain an address. (I changed "piece of memory" to "region of
data storage", and "contains" to "can contain", since a pointer object
needn't actually contain the address of anything.)

So congratulations. You have successfully picked a nit.
Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?

You were not "hijacked". People disagreed with you.

[...]
 
J

jameskuyper

Richard said:
(e-mail address removed) writes: ....

Thats a lot of wind for "the compiler hides the real implementation". ....
However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.

I said that a pointer object IS a piece of memory; this follows from
the C standard's definition of the word "object". It is necessarily
true, modulo the "as if' rule. More precisely, the as-if rule allows
an implementation to use something which is NOT a pointer object, by
reason of not residing in memory, to achieve the same results as if a
pointer object had existed. However, if a pointer object is used to
achieve that result, it must by definition occupy a "region of data
storage in the execution environment ...".

....
Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?

There's a difference; the C standard describes the behavior of C
programs in terms of objects: how they are created, used, and
destroyed. An implementation can take C code that specifies the
creation of an object, and translate it in a way that doesn't actually
involve creating that object, but it can do so only by invoking the as-
if rule. It's therefore meaningful and useful to talk about the
objects in a C program, even if a particular object isn't actually
implemented as an object by a particular compiler.

Keep in mind that the number which is displayed by the debugger is not
the pointer's value, it is the pointer's representation, interpreted
as if it represented a number rather than a memory location. The
pointer's value is a memory location, not a number. While there is a
connection between that number and that memory location, it need not
be the simple kind of connection you believe to be nearly universal.

The C standard does not describe how a pointer object represents a
pointer value, and it says almost nothing about the number that can be
obtained by converting a pointer value into a number. Therefore, an
implementation is free to handle those things in any way that is
convenient to it, without needing to invoke the as-if rule. As a
result, there's little that can be meaningfully or usefully said about
such numbers, as far as C is concerned. Anything you say about those
numbers is implementation-specific, and therefore of negligible
interest to anyone using an implementation for which it isn't true.
It's also equally uninteresting to those of us who might even be using
exactly the same implementation as you, but who go out of our way to
write code in such a way that those details don't matter.
 
R

Richard Bos

A pointer object is a piece of memory that contains the address.

No. A pointer object is a piece of memory that contains the pointer.
This must, of necessity, contain an address, but it may contain other
information as well. A pointer consisting of (base address of block,
offset in block, max offset, size of elements) is quite legal.
The pointer value is the location identified by that address.

_And_ all the other information.
We don't need to mix them, we need to separate them and connect them.
Without clearly distinguishing between the representation and the
value of a pointer, and the representation and value of the thing it
points at, you can't make anyone's life easier, you're just going to
create confusion.

And the best idea is to ignore the representation while you're still
learning about pointers, and just get on with understanding their
purpose and use. Just as it's best to ignore the bit patterns in a
float: a beginner (and come to that, most advanced programmers)
shouldn't care what order the mantissa and exponent bits are in, as long
as you know what values you can put in them. Similarly, you shouldn't
need to know whether your pointers are straight numerical addresses or
tuples with rings, segments and offsets, as long as you know what
objects your pointers point at.

Richard
 
K

Keith Thompson

No. A pointer object is a piece of memory that contains the pointer.
This must, of necessity, contain an address, but it may contain other
information as well. A pointer consisting of (base address of block,
offset in block, max offset, size of elements) is quite legal.

A pointer object is a region of data storage (which may or may not be
memory) that contains a pointer value; that pointer value *is* an
address (assuming that it actually points at something, i.e., it isn't
null or indeterminate).

The standard doesn't provide a formal definition of "address", but the
way it uses the term, it's synonymous with "pointer value". See, for
example, C99 6.5.3.2p3:

The unary & operator yields the address of its operand. If the
operand type has type "type", the result has type "pointer to
_type_".

and C99 7.20.3.3p3:

The _malloc_ function returns either a null pointer or a pointer
to the allocated space.

(I actually quoted from n1256. 6.5.3.2p3 has a change bar; I don't
know what changed from C99.)
_And_ all the other information.

By definition, or at least by the standard's usage, there is no other
information.
And the best idea is to ignore the representation while you're still
learning about pointers, and just get on with understanding their
purpose and use. Just as it's best to ignore the bit patterns in a
float: a beginner (and come to that, most advanced programmers)
shouldn't care what order the mantissa and exponent bits are in, as long
as you know what values you can put in them. Similarly, you shouldn't
need to know whether your pointers are straight numerical addresses or
tuples with rings, segments and offsets, as long as you know what
objects your pointers point at.

Agreed.

My *only* quibble here is over the meaning of the word "address".
You're using it to mean a raw machine-level address (physical or
virtual) with no type information. Given that meaning, I agree with
you. It's just not the way the C standard uses the term.
 
J

James Kuyper

Richard said:
No. A pointer object is a piece of memory that contains the pointer.
This must, of necessity, contain an address, but it may contain other
information as well.

I didn't say anything to suggest that it couldn't contain additional
information.

....
_And_ all the other information.

I was using "address" is a more abstract sense than you are: I meant, by
"address", all of the information needed to identify the location. A
pointer can also contain other information which isn't needed to
identify the location.
And the best idea is to ignore the representation while you're still
learning about pointers, and just get on with understanding their
purpose and use.

You don't need to know what the representation is; even for a
long-experienced professional, the issue is seldom important. I happen
to know from experience that, on the machine I use most often, pointers
are 4 bytes long, null pointer values happen to be represented by 0, and
non-null pointer values usually start with 0xffffff.... I don't know or
care why that is the case, and I can't think of any use I've ever made
of any of those facts except the size; and I know nothing else about how
pointers are represented on that machine - because I don't need to know.

However, any C programmer does need to understand, from a fairly early
point in the learning process, the concept that C objects (including
pointer objects) are pieces of memory that contain the representation of
a value. Without a proper understanding of the key distinction between
representation and value, much of C remains opaque and mysterious.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top