"Referenced type "

[saurabh29789]

I was going through the C Standard and came across the following :

A pointer type may be derived from a function type, an object type, or
an incomplete type, called the referenced type. A pointer type
describes an object whose value provides a reference to an entity of
the referenced type. A pointer type derived from the referenced type T
is sometimes called ‘‘pointer to T’’. The construction of a pointer
type from a referenced type is called ‘‘pointer type derivation’’.


This has kind of confused me. What I interpret is that " the address
that the pointer holds is a reference to the referenced type" and "
the referenced type is nothing but a type of the object to which the
pointer points".

Am I right?

 

[Guest]

I was going through the C Standard and came across the following :

A pointer type may be derived from a function type, an object type, or
an incomplete type, called the referenced type. A pointer type
describes an object whose value provides a reference to an entity of
the referenced type. A pointer type derived from the referenced type T
is sometimes called ‘‘pointer to T’’. The construction of a pointer
type from a referenced type is called ‘‘pointer type derivation’’..

This has kind of confused me. What I interpret is that " the address
that the pointer holds is a reference to the referenced type" and "
the referenced type is nothing but a type of the object to which the
pointer points".

Am I right?

I think so, though I think they were trying to write it
without using the word "address". A pointer doesn't *have*
to be an address, though nearly all modern implementations
do make a pointer an address.

I think mainframes used to do rather odd things with pointers
and machines that weren't byte addressable sometimes encoded
extra stuff into the pointer (eg. the byte offset). Then there
are "fat pointer" implementations that try and do bound checking.
I think the C compiler for the Lisp machines used to do stuff
like that

 

[Richard]

I think so, though I think they were trying to write it
without using the word "address". A pointer doesn't *have*
to be an address, though nearly all modern implementations
do make a pointer an address.

I think mainframes used to do rather odd things with pointers
and machines that weren't byte addressable sometimes encoded
extra stuff into the pointer (eg. the byte offset). Then there
are "fat pointer" implementations that try and do bound checking.
I think the C compiler for the Lisp machines used to do stuff
like that

Look - a pointer IS an address. It is the ADDRESS of where the DATA
is.

It really can be that simple. No one cares how its decoded.

 

[Keith Thompson]

Finally, that business about "address." Pointer values are not
addresses, or at any rate not merely addresses. Remember, a pointer
has a type: There's no way to declare a pointer without mentioning
the type that it points to, and this type information is crucial to
the use of the pointer's value.

[...]

I understand what you mean, and what you mean is perfectly correct,
but strictly speaking what what you say is not.

A pointer value *is* an address. That's what the word "address"
means in C. (Well, almost; a null or indeterminate pointer
value isn't an address, but all addresses are pointer values.)
Consider C99 6.5.3.2p3:

The unary & operator yields the address of its operand.

What you mean is that a pointer value (C address) isn't merely
a machine address, where a machine address might be, say, a 16-
or 32- or 64-bit quantity that refers to a particular location in
physical or virtual memory, but carries no information about what's
stored in that location.

Typically a C pointer value consists of a stored machine address
(bits that can be the representation of a pointer object) plus a
type (a piece of information managed by the compiler but not stored
during execution). The type information allows the compiler to
generate code that uses the (machine) address properly, so that
``*p1 = *p2'' copies the right number of bits, or is rejected if
the types are incompatible.

[...]

(IMHO the C Standard should not use the word "address" at all --
but that's a rant for another thread.)

That might not be a bad idea (not using the word "address", that is).
And I look forward to your rant.

My suggestion is that when using the word "address" here in
comp.lang.c, we should be careful to make it clear whether we're
talking about C addresses (pointer values) or machine addresses,
at least when the distinction matters.

 

[Keith Thompson]

Maybe I'm wrong but I thought void was the absence of a type.

True it can't be used in the normal sense of use without casting it, but I
thought that was because void had no type.

No, void is a type. C99 6.2.5p19: "The void type comprises an empty
set of values; it is an incomplete type that cannot be completed."

You can't declare an object of type void (or of any other incomplete
type, such as "struct this_type_has_not_yet_been_defined").

Note that the "void" keyword is used in one or two other ways that
don't refer to the type called void. For example, in a function
declaration "void foo(void)", the second "void" means that the
function has no parameters, not a single parameter of type void (which
would be illegal).

The first "void", which specifies the type that the function returns,
either refers to the type "void", or is a special case meaning that
the function doesn't return a value; I'm not sure which. The standard
seems to say that it's the former, but I haven't studied it
sufficiently to be sure.

 

[Nelu]

[...]

Finally, that business about "address." Pointer values are not
addresses, or at any rate not merely addresses. [...]
(IMHO the C Standard should not use the word "address" at all --
but that's a rant for another thread.)

So then you'd have to say that a pointer contains a... pointer to a value?
A pointer's value is a pointer? A pointer consists of a type (e.g. int*)
and an address (e.g. 0x8F12A397), to point at a particular int, just as
something like a numeric variable consists of a type (e.g. int) and some
set of bits (e.g. 0xFFFFFFFF) to form the value, -1.

A pointer is a data type whose values refers to/points to another value. So
the value of a pointer is a reference/pointer with the difference that the
first 'pointer' referes to the C data type and the second 'pointer' refers
to the English word.

For example, an address would be my home address. Two houses north of my
house is still a very good pointer but it's not an address.

 

[Richard]

Exactly. C definitely has a notion of an address, as anyone can
check with regard to how the standard defines the unary &
operator, which is called the what? THE ADDRESS OPERATOR. If
Keighley is talking about machine-specific decoding of what
C considers an address, then he is "off-topic" by his own rules.
On comp.lang.c, an address is what the Standard defines it
as, and the Standard definitely speaks of addresses in connection
to pointer values.

I can't believe that Keighley was issuing warnings about
other posters not having their C statements critiqued.
Unbelievable what this newsgroup has turned into with
the Nick Keighleys, Chuck Falconers, Phil Carmodys,
and Mark McIntyres running amok. Defies belief.


Yours,
Han from China

These guys get on my tits. I dont need their go ahead for such
terminology. The picky arseholes here are the problem with confusion
not the solution. Use the English language where you can else you'll
never get anywhere.

Its like dereferencing a pointer and the same petty smarties think its
"confusing" to suggest a pointer references a data structure for example
"in English".

Invariably the people making these objections have never worked in teams
or educated students/new employees and think they're being clever by
being so pedantic.

 

[Keith Thompson]

[...]

Finally, that business about "address." Pointer values are not
addresses, or at any rate not merely addresses. [...]
(IMHO the C Standard should not use the word "address" at all --
but that's a rant for another thread.)

So then you'd have to say that a pointer contains a... pointer to a value?
A pointer's value is a pointer? A pointer consists of a type (e.g. int*)
and an address (e.g. 0x8F12A397), to point at a particular int, just as
something like a numeric variable consists of a type (e.g. int) and some
set of bits (e.g. 0xFFFFFFFF) to form the value, -1.

The unadorned word "pointer" is ambiguous; it can refer either to a
pointer value (which C also calls an "address"), or to a pointer
object.

A pointer object contains a pointer value. That pointer value may
point, not to a value, but to an object. 42 is a value; &42 doesn't
exist, or even make any sense. Given "int x = 42;", x is an object of
type int; &x is the address of that object, and is of type int*.

Strictly speaking, 0x8F12A397 is an integer constant whose value,
expressed in decimal, is 2400363415, and whose type is either int,
unsigned int, long int, or unsigned long int, depending on the ranges
of those types. But I presume that you meant 0x8F12A397 to refer to a
particular *representation*, a pattern of bits that might be stored in
a pointer object of type int*. (C has no notation for representations
as opposed to values, so 0x8F12A397 is a convenient shorthand.)

Yes, an object of type int* might contain a bit pattern (its
representation) corresponding to 0x8F12A397, and that bit pattern
might correspond to the machine address of some object of type int, if
the implementation chooses to use machine addresses as its
representation for pointer objects (most implementations do).

The previous paragraph could probably be made considerably shorter,
resulting in reduced strict accuracy but perhaps greater
understandability.

 

[Bartc]

<[email protected]>
wrote:
[...]

Finally, that business about "address." Pointer values are not
addresses, or at any rate not merely addresses. [...]
(IMHO the C Standard should not use the word "address" at all --
but that's a rant for another thread.)

So then you'd have to say that a pointer contains a... pointer to a
value?
A pointer's value is a pointer? A pointer consists of a type (e.g. int*)
and an address (e.g. 0x8F12A397), to point at a particular int, just as
something like a numeric variable consists of a type (e.g. int) and some
set of bits (e.g. 0xFFFFFFFF) to form the value, -1.

A pointer object contains a pointer value. That pointer value may
point, not to a value, but to an object. 42 is a value; &42 doesn't
exist, or even make any sense. Given "int x = 42;", x is an object of
type int; &x is the address of that object, and is of type int*.

I used to have a problem understanding the difference between, say, an int
object and an int value, especially in languages having proper constants.
Imagine C has a 'constant' prefix, similar to an enum:

int x;
constant int y=42;
x=41;

Both x and y are of type int, yet &x is allowed but not &y.

The answer is that a variable such as x above is actually a 2-level value,
while the constant exists at a single level. The language hides this
difference. In reality, the above is actually:

constant int *x = A; /* A is some address the compiler assigns */
constant int y=42;
*x=41;

So x is just a pointer value (type int*) to which the compiler assigns (or
equates to) an address of a reserved location suitable for an int value. And
the compiler also automatically dereferences these pointer values, so that
every x written is treated as (*x).

Now it's easy to see that &(*x) will work: the & and * cancel, leaving x
(which has value A); and that &y can't work, because in this scenario & can
only be used to cancel a * dereference.

(And if the OP isn't totally confused by now, that will be surprising.)

 

[Keith Thompson]

I used to have a problem understanding the difference between, say, an int
object and an int value, especially in languages having proper constants.
Imagine C has a 'constant' prefix, similar to an enum:

int x;
constant int y=42;
x=41;

Both x and y are of type int, yet &x is allowed but not &y.

The answer is that a variable such as x above is actually a 2-level value,
while the constant exists at a single level. The language hides this
difference. In reality, the above is actually:

constant int *x = A; /* A is some address the compiler assigns */
constant int y=42;
*x=41;

So x is just a pointer value (type int*) to which the compiler assigns (or
equates to) an address of a reserved location suitable for an int value. And
the compiler also automatically dereferences these pointer values, so
that every x written is treated as (*x).

Ok, but there's some potential confuse here because you're using "x"
and "*x" to refer to what are actually "&x" and "x", respectively, in
my code snippet.

But you're right about the 2-level value thing. We used to use the
terms "lvalue" and "rvalue" to express this. An expression could be
evaluated in two different ways. Evaluating it for its lvalue yields
the identity of the object to which it refers (this isn't possible if
it doesn't refer to an object). Evaluating it for its rvalue yields
what we generally call the value of the expression.

(I *think* I've got the history right.)

Unfortunately, IMHO, the C standard uses the term "lvalue" to mean an
expression that refers to an object, not to the result of evaluating
such an expression, and we're stuck with that using. (This meaning of
"lvalue" goes back at least to K&R1 in 1978.)

[...]

 

[Bartc]

Ok, but there's some potential confuse here because you're using "x"
and "*x" to refer to what are actually "&x" and "x", respectively, in
my code snippet.

From an Asm point of view, x is the address and the *x (or [x]) is the
contents of what's called a variable.
A HLL like C will make x normally refer to the contents, by automatic
dereferencing, so that a special op & is needed to get back the address;
while doing *x is an error unless the contents of x also have pointer type:

Asm C
Address x &x
Contents *x x

But you're right about the 2-level value thing. We used to use the
terms "lvalue" and "rvalue" to express this. An expression could be
evaluated in two different ways. Evaluating it for its lvalue yields
the identity of the object to which it refers (this isn't possible if
it doesn't refer to an object). Evaluating it for its rvalue yields
what we generally call the value of the expression.

Unfortunately, IMHO, the C standard uses the term "lvalue" to mean an
expression that refers to an object, not to the result of evaluating
such an expression, and we're stuck with that using. (This meaning of
"lvalue" goes back at least to K&R1 in 1978.)

Lvalue/rvalue /are/ a little confusing, because the same amount of
dereferencing goes on for each. When I do compiler stuff, I evaluate a
simple variable x as follows:

lvalue: *(&x)
rvalue: x

So both have equivalent dereference levels (both refer to say an int
location to have an int value stored or retrieved), but the & in the lvalue
makes sure you can't do this for example:

43 = 0;

 

[Keith Thompson]

It is a warning, not a diagnostic.

A warning is a diagnostic.

Sounds like the answer "It is noon" to the question, "It is sunny outside?"

Methinks they are grasping at circular logic straws to make a raft.

You said you thought void was "the absence of a type". You were
mistaken; void is a type. There is no circular logic.

Now the type void is unique in several ways. If you want to ask about
that, feel free to do so.

 

[Keith Thompson]

A pointer is a data type whose values refers to/points to another
value.

A pointer *type* is a data type whose values may refer to/point to an
*object* (or to a function, or to nothing if the value is null or
indeterminate). A pointer type, a pointer value, and a pointer object
are very different things, and any of them may be referred to as a
"pointer".

So the value of a pointer is a reference/pointer with the
difference that the first 'pointer' referes to the C data type and
the second 'pointer' refers to the English word.

For example, an address would be my home address. Two houses north of my
house is still a very good pointer but it's not an address.

Golden California Girls posted an example: if p is the address of an
object within a sufficiently long array, then p + 2 is the address of
another object within that array; p + 2 is also a pointer value.

 

[Kaz Kylheku]

If speaking precisely, I wouldn't say "a pointer contains" at
all, though I'd say "a pointer variable contains" something.

Note that the bit string 10101 contains 010.

You're not being imprecise if you say, for instance, that some floating point
representation contains a sign, exponent and mantissa.

 

[Eric Sosman]

[...]

I understand what you mean, and what you mean is perfectly correct,
but strictly speaking what what you say is not.

Well, I *did* say that I was trying "to build a bridge
between exactness and understanding." If such a bridge had
both ends and the middle firmly grounded in exactness, I put
it to you that it would be a bridge to nowhere.

 

[Eric Sosman]

It is a warning, not a diagnostic.

It is a diagnostic, period. You will search for the word
"warning" in vain in the normative portions of the Standard.

Sounds like the answer "It is noon" to the question, "It is sunny outside?"

Methinks they are grasping at circular logic straws to make a raft.

Can you not even read? Next time you girls gather for a
sleep-over and Barry Manilow rave, ask some literate person to
recite the Standard aloud to you. Pay attention, if you can.

 

[Nelu]

A pointer *type* is a data type whose values may refer to/point to an
*object* (or to a function, or to nothing if the value is null or
indeterminate). A pointer type, a pointer value, and a pointer object
are very different things, and any of them may be referred to as a
"pointer".

I realized that too late. "A pointer type describes an object whose value
provides a reference to an entity of the referenced type." sounds better. I
have completely disregarded the other cases.

Golden California Girls posted an example: if p is the address of an
object within a sufficiently long array, then p + 2 is the address of
another object within that array; p + 2 is also a pointer value.

Yes. But my analogy was related to the meaning of the word 'address'. We
can build p using the address (postal address in this case) but p+2 may not
have a postal address, however, you can still have a pointer that points to
it constructed in a different way. Not sure if this makes any sense or not.

 

[Nelu]

[...]

Yes. But my analogy was related to the meaning of the word 'address'. We can
build p using the address (postal address in this case) but p+2 may not have
a postal address, however, you can still have a pointer that points to it
constructed in a different way. Not sure if this makes any sense or not.

You go outside C in using Postal Addresses (physical memory addresses). If
the implementation can pull it off, consecutive C pointers could be on
different machines.

Yes. I guess I found the word 'address' too close to particular hardware
constructions to be appropriate for a portable definition of a pointer. But
I'm sure that's just a subjective observation since the standard doesn't
seem to mind the word .

 

[Keith Thompson]

Didn't I just read here in the last day that only an error was a
diagnostic?

I don't think so. If someone actually said that, they're wrong.

The standard defines a "diagnostic message" as a "message belonging to
an implementation-defined subset of the s message
outputimplementation". There is no distinction in the standard
between warnings and error messages.

 

[Keith Thompson]

It is a type! No its not, it isn't complete. Which is it?

An incomplete type is a type.