Where do pointers point to?

[S.Tobias]

Nit-pick: While I perfectly understand the intention, it doesn't make
sense reading strictly. Object and incomplete types are disjoint groups
(ie. object types are not divided into complete and incomplete types
- I fell into this trap recently), although both describe objects (6.2.5#1).
IMHO it'd be better to say: "void* is an object pointer".

[/QUOTE]

Don't confuse the type of a pointer and what it points to. Usually there
is a direct relation but not with pointers to incomplete types. It is
perfectly reasonable for a pointer to an incomplete type to point at an
object,

[snip]

I fully agree. Jacks Klein's words could be understood as: "a (pointer
to object) type", but then I think the parentheses would be necessary.
I'm not going to argue on the precedence of word linkage in English
language, but my common/colloquial/vulgar/illiterate*) understanding
was "a pointer to (object type)". /Object type/ can never be
/incomplete type/ and v.v., and neither can be type pointer to thereof.
I made my remark for those who might be confused like I was before.

*) choose most appropriate

I hope I'm sufficiently clear.

 

[Mark Piffer]

An example situation in described system could be:

int x;
&x == 0x4003
(void *)&x == 0x4003
(char *)&x == 0x4000
(void *)(char *)&x = 0x4000

No; (char *)&x would be == 0x4003. The first byte would be at address
0x4003, the second byte at address 0x4002, and so on. ((char *) &x) + 1
would be == 0x4002. If you compare ((char *) &x) < ((char *) &x) + 1,
the result is true (1).[/QUOTE]

I apologize for my other, pointless, posting. Only after submitting I
noted the subtle requirement you stated, that is, making a
*non-portable* app running on a reverse endianess architecture. Of
course your reasonings are correct (as always .

Mark

 

[Lawrence Kirby]

Don't confuse the type of a pointer and what it points to. Usually there
is a direct relation but not with pointers to incomplete types. It is
perfectly reasonable for a pointer to an incomplete type to point at an
object,

[snip]

I fully agree. Jacks Klein's words could be understood as: "a (pointer
to object) type",

However I'm uneasy about your statement "void* is an object pointer" for
similar reasons. It mixes too many concepts to provide a clear statement
of what is happening. In terms of type void* isn't an object pointer.
However at runtime a void* pointer is capable of pointing at objects in a
loose sense.

Lawrence

 

[S.Tobias]

void* is a pointer to object type, even though it happens to point to
an incomplete type that can't be completed.

Nit-pick: While I perfectly understand the intention, it doesn't make
sense reading strictly. Object and incomplete types are disjoint groups
(ie. object types are not divided into complete and incomplete types
- I fell into this trap recently), although both describe objects (6.2.5#1).
IMHO it'd be better to say: "void* is an object pointer".

Don't confuse the type of a pointer and what it points to. Usually there
is a direct relation but not with pointers to incomplete types. It is
perfectly reasonable for a pointer to an incomplete type to point at an
object,

[snip]

I fully agree. Jacks Klein's words could be understood as: "a (pointer
to object) type",

[/QUOTE]

However I'm uneasy about your statement "void* is an object pointer" for
similar reasons. It mixes too many concepts to provide a clear statement
of what is happening.

Now what did I say wrong? The Standard itself uses words (but not terms)
"function pointers" and "object pointers". Grep through n869.txt.
What's this hair-splitting about?

In terms of type void* isn't an object pointer.

Why? The Standard demands that void* be able to point to objects, and
nothing else.

Besides, see 7.18.1.4 and look what "object pointers" in the title
refers to.

However at runtime a void* pointer is capable of pointing at objects in a
loose sense.

My understanding has been an "object" to be a range of memory where
values can be stored. What "looser" sense can there be? Perhaps
void* can point to other things too, like functions, but these
are extensions.

 

[pete]

S.Tobias wrote:

Now what did I say wrong?
The Standard itself uses words (but not terms)
"function pointers" and "object pointers". Grep through n869.txt.
What's this hair-splitting about?

My C89 last public draft also has the substrings of
"object pointer" and "function pointer"

I like the term "object pointers" to refer to pointers to
object types and pointers to incomplete types collectively,
and I like "function pointers" to mean pointers to function types.