"Mastering C Pointers"....

[Keith Thompson]

TIWITAW.

W?

 

[Arthur J. O'Dwyer]

Yes, I did indeed, but ruse's and Roose's postings are definitely of
different style. And I do not consider either one to be smart enough
to successfully pretend to be somebody else.

Remember ruse: "... again, spoke your nose!" makes me still ROFL.

No, that one was ROSY. Google "spoke ur nose"...
I don't think we've ever had a troll named "ruse."
http://dictionary.reference.com/search?q=ruse

-Arthur,
maybe it *is* best not 2 spoke my nose on this matter

 

[Joona I Palaste]

W?

That Is What I Thought As Well.

 

[Mark McIntyre]

int a;
&a;

(&a) is a pointer, but not an object.

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .

 

[Mark McIntyre]

int i = 6;
int * const p = &i; /* p is not a variable - or at least, to persuade anyone
that it is, you'd have to have kissed the Blarney. */

Actually p is a variable. It merely happens to have an immutable
value.

 

[Joona I Palaste]

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .

This depends on the definition of a "pointer". Is it a value or a
variable?

 

[pete]

I disagree. (&a) in that context is an expression.

Being an expression, doesn't make it not a pointer.
It's a pointer expression.

To be a pointer, it
would have to be stored in something.

That would be a pointer object.
A reference to a pointer object, would be an expression too.

'1' is an integer expression.
'1' is an integer, isn't it ?

 

[Arthur J. O'Dwyer]

Also, I think there is an important difference between the concepts
of "variable" and "object". A variable is a named, typed, object.

I'd say that's correct.

An object is, by itself, only storage. It can store a value, but
doesn't have any inherent type or name.

The Standard says that an object has a type. Why else would we
discuss "objects of type T" and "objects of type U"?

So in my little hierarchy of abstractions, I would stick another
one on the bottom: "memory." Objects are kind of "chunks" of
memory, which have types. Memory itself is just a bunch of bytes,
without type information attached.
'malloc' and friends notably return pointers to memory, not
pointers to objects. The program can *access* parts of that memory
as if they were objects of a given type, e.g.:

void *p = malloc(42);
int q = *(int *)p; /* treat the space pointed to by 'p' as
* if it were an object of type 'int' */

The idea of a "typeless" object is meaningless -- all objects
have sizes, for example, and what's the size of an object without
a type? If I write

int i = 42;
void *p = &i;

then 'p' does not have the type 'pointer to object of type X' for
any X -- i.e., 'p' doesn't have any information about the type of
the object to which it points -- but it's still actually pointing
to an object of type 'int': namely, 'i'.

Summary:
Variables have names (but I wouldn't use that word myself).
Objects have addresses, types, and sizes.
Memory (or "space") is typeless and composed only of bytes.

my $.02,
-Arthur

 

[Mark McIntyre]

I can agree with that, but my impression is that this reasonable stance is
not the one that the majority of those in this newsgroup take.

Eh? Its /precisely/ the reasonable stance that teh majority of us
take. You're the one that has a problem with it.

I undestand this, but again my contention is that such bugs would be quite
obvious.

You're quite wrong. Elsethread an example of where your idea fails
even for a single architecture has been presented.

You should /never/ make platform specific assumptions in code you plan
to port, and you should avoid making platform specific assumptions
elsewhere except when you actually need to. Thats how you avoid bugs
like this.

Code that depends on this simply would not work when ported and
tested for this first time.

It might work, but have an obscure bug. For example, I once ported a
DVI2HP implementation from Unix to MS-DOS. If you know DVI, you'll
know that its essentially a binary file format for printing, and
consists of encoded instructions telling the print engine where to
place the cursor, what font to use, what colour, how long a line will
be drawn and at what angle etc.

The original implementor read blocks of data from the DVI file using
fread, and generally was a good boy, but very occasionally assumed
that sizeof(int) was the same as sizeof(long). On MSDOS it wasn't.
This obscurely broke the code when very specific DVI was encountered,
as too little data was read. This DVI happened to be rarely used, and
the obscure break was something like picking the wrong colour, or
drawing a line too short. So this went entirely unnoticed during
testing.

But my larger point stands, that for pedagogical purposes, it is a useful,
concrete statement to say that a pointer is not unlike an array index.

Except that array indices need not be integers. Consider library
shelves using the Dewey system, C++ vectors etc. Consider MS-DOS's
segmented architecture, where a pointer was two integers.

An integer. Yes there can be other bits set, and so forth. But if you were a
C programmer who was NOT aware of this fact, I would seriously question you.

Many are when they start out. They only learn it by being told the
right answer, instead of an erroneous concept.

 

[Mark McIntyre]

(lots of ramble)

and now we know why newbies think pointers are tricksy, wicked or
false....

 

[pete]

Arthur J. O'Dwyer wrote:

The Standard says that an object has a type.

malloc returns a pointer to a typeless nameless object.

 

[Ben Pfaff]

The Standard says that an object has a type. Why else would we
discuss "objects of type T" and "objects of type U"?

The Standard does not say that. Here is the definition of
"object" in C99:

1 object
region of data storage in the execution environment, the
contents of which can represent values
2 NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.

 

[Richard Heathfield]

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .

I think I'm going to have to ask for chapter and verse on that. Or I can
simply give you a counter-example: NULL. You see, NULL is most definitely a
pointer, and yet, in the expression if(p != NULL) the NULL is not "stored
in anything" - that is, the RHS of the != is not the value of an object.

 

[Arthur J. O'Dwyer]

malloc returns a pointer to a typeless nameless object.

N869 disagrees with you, although it's quite possible
that the standard Standard changed the wording:


7.20.3.3 The malloc function

Synopsis
[#1]
#include <stdlib.h>
void *malloc(size_t size);

Description

[#2] The malloc function allocates space for an object whose
size is specified by size and whose value is indeterminate.

Returns

[#3] The malloc function returns either a null pointer or a
pointer to the allocated space.


"Pointer to allocated space", not "pointer to allocated object."
The allocated space is *big enough* to *hold* an object, but N869
significantly omits to say it actually *is* one. See?

Yeah, the Standard is kind of wishy-washy on this issue.
But it supports my opinion, which of course I think is only
common sense.

-Arthur

 

[pete]

Sheldon Simms wrote:

The bit pattern stored in a nameless typeless object,
doesn't have any inherent value either.

After rereading the standard, I see that you are 100% correct
and I was wrong.

N869
6.2.5 Types
[#1] The meaning of a value stored in an object or returned
by a function is determined by the type of the expression
used to access it.

 

[pete]

I see a definition of object that doesn't mention type.

"Pointer to allocated space", not "pointer to allocated object."

"allocated space", fits the definition of object.

N869
3. Terms and definitions
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values

 

[Ben Pfaff]

I disagree. (&a) in that context is an expression. To be a pointer, it
would have to be stored in something. .

The standard does not define the term "pointer", but it often
uses it with the implied meaning of "value of pointer type". For
example, take this paragraph from C99 6.3.2.3:

7 A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the
resulting pointer is not correctly aligned57) for the
pointed-to type, the behavior is undefined. Otherwise, when
converted back again, the result shall compare equal to the
original pointer. When a pointer to an object is converted
to a pointer to a character type, the result points to the
lowest addressed byte of the object. Successive increments
of the result, up to the size of the object, yield pointers
to the remaining bytes of the object.

Each use of "pointer" in this paragraph means "value of pointer
type", because the alternative, that each of them means "object
of pointer type", doesn't make sense. A few of them are
debatable, but all of them taken together should make it clear
that a pointer can be a value.

 

[Mark McIntyre]

This depends on the definition of a "pointer".

As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.

Mornington Crescent.

 

[Mark McIntyre]

I think I'm going to have to ask for chapter and verse on that. Or I can
simply give you a counter-example: NULL. You see, NULL is most definitely a
pointer,

Well..... NULL is a macro, which is converted by the preprocessor to a
constant inserted literally into the processed code, whose value is
selected to be the one the implementation uses to mean "I point
nowhere". So its not actually a pointer at this point. If you see my
point.

and yet, in the expression if(p != NULL) the NULL is not "stored
in anything" - that is, the RHS of the != is not the value of an object.

But thats fine - its not a pointer either...

 

[Ben Pfaff]

As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.

See my post elsethread for why that's a bad definition.

Mornington Crescent.

I have no idea what that means. Is it a breakfast food?