"Mastering C Pointers"....

[Richard Heathfield]

Hilarious. Back to children's games, I see.

No. I am not a mind-reader. I answer to what you say, not to what you might
or might not mean. You asked me to give you a break, and I'm happy to
oblige. If you have a problem with taking a break, why ask me for one?

As would many of yours.

It's possible, but irrelevant, since I never start these kinds of
disagreement anyway. But, as it happens, although I don't regularly read
clcm, I have had around 90 articles posted there, according to Google.

Stop with the sniveling wordplay already.

Do you always resort to abuse when you run out of logic?

I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking.

And that's why we treat the concepts so seriously here, the ones that you
seem so loathe to recognise as important - such as the concept of "object".

That's why I specifically said that you need at
least TWO perspectives. I encourage them to read
your article. My claim is that that's not sufficient.
They should read a concrete explanation like mine.
Together they will help you understand pointers.

Specific discussions of particular platforms /are/ sometimes held here, but
they normally demonstrate why concrete experience can be misleading rather
than enlightening.

[...] The real question was about pointers.

OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES.

I think that the OP wanted to study pointers so that he could understand
them. That is why I answered as I did. To derive one's "understanding" of
pointers from a particular platform is a foolish thing to do. There are
still people who think that C has "near" and "far" keywords, and who are
rather surprised when their pointer code suddenly stops working when moved
to a different target machine. They have learned pointers your way. They
should have learned them properly, didn't, and now pay the price.

Q.E.D. Another perfect example of why my underemployed flames were so
accurate.

I do not have such a huge amount of spare time that there is not a cost to
the community associated with my taking time out to debunk your errors.

Everybody else is wrong; and you're right.

At last you understand.


<snip>

 

[Roose]

Chris, I enjoyed reading your post and there is definitely interesting
information here. But I would contend that if someone doesn't yet have a
good understanding of pointers, he won't have the foggiest idea what you're
talking about. : )

Good, because there are machines on which this is not the case.

C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.

(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)



I am not sure which part you "don't get", but be aware that this,
too, is not required of systems that will run C, and indeed, there
are systems on which it is not true, or at least only partly true.
One of them was very common only a decade ago: the 80x86 CPU in
the ordinary IBM PC has non-linear ("segmented") addressing, and
in 16-bit modes -- which are no longer used for much, but were all
one had until the 80386 came out -- a memory address was made up
of segmentffset pairs.

Of course, actually using this to good effect was slow at best,
and a lot of old C compilers for the x86 used bizarre modifiers
(spelled "far" and "near" in some cases; now more like _FAR and
_NEAR in backwards compatible modes) to let you mix "fast" code
that avoided the use of segments with "slow" code that used segments
so as to be able to break the "64K barrier" (or rather, 128K, with
64K of code and 64K of data, in a split I&D design reminiscent of
some PDP-11s, where C was originally developed).

All C really requires of memory is that it be able to store values,
and that it be "addressable" in some way. Which is where the pointers
that are in the "subject:" line here come in -- taking the address
of a memory region holding a C "object" yields a pointer to that
object.

Actually, C does impose a few more conditions on memory. In
particular, C requires that arrays be (or at least seem to be)
contiguous. An array is defined by its "element type" and a numeric
size -- in C89, an integer constant like 42 -- and an array must
be stored in memory as a contiguous sequence of that many of those
elements. Each element is itself an "object" (region of storage),
but the array as a whole is an object too, just a composed one.

If all of a given computer's memory is one big blob of bytes in
sequence, which is certainly an easy way to build a computer, then
it is equally easy to divide up this one blob any way you like.
But C does allow other arrangements, which can have add security
or reliability features for instance, as long as the resulting
memory can be grouped together to hold arrays. Other than those
arrays, there is no *requirement* that there be a neat numerical
sequencing of "all memory"; it just happens to be pretty common,
because it is so easy.

(As an aside: on modern operating systems, "memory" is usually an
illusion anyway. The OS will *simulate* a nice linear sequence of
bytes, but it does so with "pages" that are "paged in" and "paged
out" to/from some form of "backing store" -- typically on disk --
and shuffled and reshuffled without any individual program, whether
coded in C or any other language, being able to see what is happening.
The hardware must provide a certain amount of assistance to let
the OS know what a program is trying to do, and the OS then determines
whether the code is doing something "normal" and "allowed", and if
so, arranges to allow it. The OS can then also determine whether
the program is running amok, and if so, stop it. While large chunks
of OSes can be written in nothing other than strictly conforming
C code, parts *must* be written using stuff outside the C standard,
and often must be hand-coded in assembly. These include the parts
that talk with hardware to find out what the various user programs
are attempting.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to

spammers.

 

[Alan Connor]

Good, because there are machines on which this is not the case.

Wouldn't ya know it...

C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.

(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)

Well, it's incomprehensible and therefore SHOULD be OT

I am not sure which part you "don't get",

90% of this post, as a matter of fact.

Thanks for the effort, but I'm still not exactly sure what an object is.

(except that they aren't 3-dimensional constructions having weight and mass)

Co-processing parallel non-linear 16-bit sugar-free oscillators are a
wee bit over my head...

 

[Alan Connor]

On the contrary, it's simply a false statement. The term /is/ in the index
of K&R2.

--

You are right. I was looking at the C Answer Book. Sorry.

But the explanation in K&R is not nearly as good as the ones I received
from you and others here.

 

[Morris Dovey]

On the contrary, it's simply a false statement. The term /is/
in the index of K&R2.

In my 1978 first edition of K&R, Chapter 0, page 3:

"In C. the fundamental data objects are characters, integers of
several sizes, and floating point numbers. In addition, there is
a heirarchy of derived data types created with pointers, arrays,
structures, unions, and functions."

The term did not appear in the index of K&R1; and one needs to do
a little reading to find it - but only a /little/ since the
quoted text appears at the very top of page three.

Probably the "C programmers" referred to are those who prefer
ignorance to the drudgery of reading all that boring technical
literature and learning the associated vocabulary - self-styled
'free spirits' and all that (the kind who only check the value
returned from critical functions when they're in the mood.)

 

[Richard Heathfield]

The term ["object"] /is/ in the index of K&R2.

In my 1978 first edition of K&R, Chapter 0, page 3:

"In C. the fundamental data objects are characters, integers of
several sizes, and floating point numbers. In addition, there is
a heirarchy of derived data types created with pointers, arrays,
structures, unions, and functions."

Parcel the book up carefully. I'll send you my mailing address under
separate cover.

Probably the "C programmers" referred to are those who prefer
ignorance to the drudgery of reading all that boring technical
literature and learning the associated vocabulary - self-styled
'free spirits' and all that (the kind who only check the value
returned from critical functions when they're in the mood.)

I'm afraid that this point will be lost on the very people who could learn
most from it, but that doesn't make it any less true.

 

[Irrwahn Grausewitz]

It wasn't "gibbering", it was very helpful.

If you find misleading, off-topic and partly incorrect information
given by an individual having horrible misconceptions about how C works
helpful: your decision. Just be prepared for others to disagree.

A lot more helpful than this.

Indeed; why did you post it then?

Regards

 

[Peter \Firefly\ Lund]

Perhaps it wouldn't be a bad idea to learn a little assembly language at
this point?

It would be a very good idea. Just don't fall into the trap that Roose
does: that all the world looks like the particular cpu you have learnt.

There are many things that seem natural and obvious if all you know is a
typical CPU architecture and a not too smart C compiler. Things which
aren't actually C but only happen to work. Sometimes.

May I also point out that quoting the ANSI standard to a novice is about
as useful as replying in Swahili

Telling you fantasy stories that sound right but aren't shouldn't be very
useful, either

-Peter

Being really good at C++ is like being really good at using rocks to
sharpen sticks.
-- Thant Tessman

 

[Thomas Stegen]

Thanks for the effort, but I'm still not exactly sure what an object is.

(A bit informal here)
You can say that a variable has two parts. A name and somewhere
to stay in memory. The name is an identifier and the part that
is stored in memory is the object.

So if you do this:

int i;

You will get an area of memory where you can put values by
doing stuff like i = 3; i is the name of this area of storage.

So you can say that an object is the actual area of memory
where the values of the variable is stored.

 

[Roose]

Alan,

Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.

And yes, I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. And
I write code that is portable across the 3 consoles.

 

[Joona I Palaste]

Alan,

Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.

Would these trolls have names like Heathfield and Grausewitz? In that
case you have a pretty weird definition of "troll".

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[pete]

Alan Connor wrote:

Thanks for the effort,
but I'm still not exactly sure what an object is.

An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.

There's three main ways of allocation:
1
int object_1 = 0;
object_1, is an ordinary variable.
2
char *pointer_1 = "object_2";
char *pointer_2 = "object_2";
"object_2" is paradoxically, the name of an anonymous object.
pointer_1 and pointer_2, may or may not point to the same object.
3
pointer = malloc(sizeof object_3);
malloc returns either NULL,
or a pointer to an anonymous and typeless object.

The value of an object depends on the bit pattern in the object
and on the type of identifier used to access the object.
An object may be accessed safely by any type of identifier
as long as:
1 the size of the type of the identifier
doesn't excede the size of the object,
2 and there are no conflicts with the type of the pointer
and the alignment of the object,
3 if being read, the bit pattern read from the object,
is defined for the type of the identifier.

(*(unsigned char*)&object_1 == 0)

A pointer to any object, when cast to a pointer to char,
signed or unsigned, points to the lowest addressable byte
of the object.
The addresses of any two objects may be compared for equality
or inequality.

("object_2" != (char*)&object_1)

The addresses of any two bytes within the same object,
as well as the address of the very next byte after an object,
may also be compared with each other for greater than or less than.

((char*)&object_1 + sizeof object_1 > (char*)&object_1)

The greater than or less than comparison of the addresses
of two bytes in unrelated objects, is undefined.

/* ("object_2" > (char*)&object_1), Undefined */

 

[Roose]

Before responding, I'd appreciate it if you answer the questions you ignored
from my posts... otherwise I'm not going to bother responding to your post,
either.

If one wishes to write /correct/ C programs, an understanding of the
principles laid out in the Standard is vital. The easiest way to achieve
this understanding is by reading and understanding the C Standard.

What percent of the total number of C programs in the world do you think are
correct in this sense?

Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?

No sarcasm there, just answer honestly.

Hilarious. Back to children's games, I see.

No. I am not a mind-reader. I answer to what you say, not to what you might
or might not mean. You asked me to give you a break, and I'm happy to
oblige. If you have a problem with taking a break, why ask me for one?

As would many of yours.

It's possible, but irrelevant, since I never start these kinds of
disagreement anyway. But, as it happens, although I don't regularly read
clcm, I have had around 90 articles posted there, according to Google.

Stop with the sniveling wordplay already.

Do you always resort to abuse when you run out of logic?

I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking.

And that's why we treat the concepts so seriously here, the ones that you
seem so loathe to recognise as important - such as the concept of "object".

That's why I specifically said that you need at
least TWO perspectives. I encourage them to read
your article. My claim is that that's not sufficient.
They should read a concrete explanation like mine.
Together they will help you understand pointers.

Specific discussions of particular platforms /are/ sometimes held here, but
they normally demonstrate why concrete experience can be misleading rather
than enlightening.

[...] The real question was about pointers.

OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES.

I think that the OP wanted to study pointers so that he could understand
them. That is why I answered as I did. To derive one's "understanding" of
pointers from a particular platform is a foolish thing to do. There are
still people who think that C has "near" and "far" keywords, and who are
rather surprised when their pointer code suddenly stops working when moved
to a different target machine. They have learned pointers your way. They
should have learned them properly, didn't, and now pay the price.

Q.E.D. Another perfect example of why my underemployed flames were so
accurate.

I do not have such a huge amount of spare time that there is not a cost to
the community associated with my taking time out to debunk your errors.

Everybody else is wrong; and you're right.

At last you understand.


<snip>


--
Richard Heathfield : (e-mail address removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

 

[Richard Heathfield]

[top-posting fixed]

Richard wrote:

<snip>

Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.

I only post replies to you when it is necessary to correct your errors. If
you don't write articles, you won't make errors, so it won't be necessary
to correct them.

I think you've stumbled across a big time-saver. Well done.

 

[CBFalconer]

It would be a very good idea. Just don't fall into the trap
that Roose does: that all the world looks like the particular
cpu you have learnt.

Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".

People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.

 

[Joona I Palaste]

People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.

I once took it upon myself to learn the assembly language of the MOS
Technologies 6502 and 6510 series. This is the only real-world processor
whose assembly language I know. Nevertheless, it has given me an insight
to how assembly languages differ from high-level languages such as C.

 

[Lew Pitcher]

I once took it upon myself to learn the assembly language of the MOS
Technologies 6502 and 6510 series. This is the only real-world processor
whose assembly language I know. Nevertheless, it has given me an insight
to how assembly languages differ from high-level languages such as C.

In college, I learned (to my later benefit) IBM 370 Assembly language. Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language. Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.

For what it's worth, I firmly believe that it would do most of the current crop
of "low level programmers" to learn IBM 370 Assembly language. This to find out
how to do things when you don't have a stack, aren't working in ASCII, and must
calculate with /very/ long decimal numbers. ;-)


--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')

 

[Alan Connor]

If you find misleading, off-topic and partly incorrect information
given by an individual having horrible misconceptions about how C works
helpful: your decision. Just be prepared for others to disagree.


Indeed; why did you post it then?

Regards

What Roose posted was very helpful to me.

I am not going to dismiss an obviously intelligent and learned person on
your say so.

 

[Alan Connor]

Alan,

Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.

And yes, I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. And
I write code that is portable across the 3 consoles.

I can tell the wheat from the chaff, Richard.

 

[Alan Connor]

Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".

I didn't need those cavils, and he was addressing me.

People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.

Thanks much. Actually sounds fascinating.