"Mastering C Pointers"....

[Alan Connor]

(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.

Thanks Thomas.

 

[Alan Connor]

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.

What's a "register (qualified) object"?

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 */

Most of that was over my head, pete. But thanks for the effort.
It will be in the archives when I'm ready for it.

 

[Alan Connor]

[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.

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.

 

[Lew Pitcher]

What's a "register (qualified) object"?

register int SomeThing;

as opposed to

int SomeThingElse;

Given
int *PointerToSomething;

you can
PointerToSomething = &SomeThingElse;
but not
PointerToSomething = &SomeThing;
because SomeThing is a register qualified object, but SomeThingElse is not.

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

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

 

[Alan Connor]

Let me preface this with some meta-comments. If your goal is to learn C, by
all means go ahead and dive right into the C language. You only learn by
making mistakes. But is a common fact in computers that you really only
master something when you have at least learned the level below it, i.e.
_what it is abstracting_. Then you see where the abstraction came from.

See these articles:

http://www.joelonsoftware.com/articles/LeakyAbstractions.html
http://biztech.ericsink.com/Abstraction_Pile.html

Will do.

So if you configure OSes, it's good to learn some scripting. If you script,
good to know some compiled programming. If you program C, good to know some
assembly/computer architecture.

Yes!


The idea was to give a simple concrete model that anyone can learn, but
don't get bogged down if your real goal is to learn C. Basically what I'm
describing is a von Neumann machine with some details (this is a very
influential hardware architecture that created the descendants of PCs,
roughly). Unfortunately with a cursory google search, I couldn't find any
good links for that, maybe someone else can help out here.


Yes, whoops.


Yes, you can think of it as inert. The CPU controls everything, the
"brain". Memory is a separate unit which just stores bits. Same with the
hard disk. Notice that as the access time increases, so does the size of
the medium.

is >> > 2^32-1, which means 4 gigs. If you have heard Apple's stupid
advertisements

The main point here was that a pointer is a C language abstraction (for an
address in memory). A pointer at the hardware level _is an integer_.
Memory is just a big array of bytes again. Say you have 1 meg of memory,
then you can just number the bytes 0 .. 1,048,575 (2^20-1). Suppose you
have a variable numFiles that is the number of files in a directory = 55.
That variable must be stored somewhere. Say it is stored at the 200,005th
byte. Then a pointer to numFiles would have the numeric value 200,004 (get
used to indexing from 0 in C). That's it. Nothing else. It's like an
array index if you think of the array as all of memory.

e.g.
int numFiles = 55;
int* pNumFiles = &numFiles; // pNumFiles is a variable of pointer
type, with the numeric value 200,004

Of course, as always, there are details, but I'm not going to clutter up
that simple concept with them. And this is very real, you can inspect
pointers in a debugger and see this (which was my suggestion).

Say you have a 32 bit register. After you learn binary/hex, you will see
why the number of different integers you can store in 32-bits is 2^32 = 4
gigs. A pointer can be thought of as an integer index, like I said. Thus
if a pointer is 32-bits, then you can only address 4 gigs of memory.


You don't actually NEED to in order to do the exercise I suggested, since
many debuggers will display all values in decimal, but it helps to get into
the mindset. It is pretty simple if you are even mildly mathematical. Hex
is really a shorthand for binary, in some sense. There are probably plenty
of tutorials on the web, but afterwards you should be able to understand
these common equivalences:

2^8-1 = 255 = 0xFF = 1111 1111
2^8 = 256 = 0x100 = 1 0000 0000 = 0.25 K
2^16-1 = 65535 = 0xFFFF = 1111 1111 1111 1111 (spaces in binary added for
clarity)
2^16 = 65536 = 0x10000 = 1 0000 0000 0000 0000 = 64 K

0x1 = 0001 b
0x2 = 0010 b
0x4 = 0100 b
0x8 = 1000 b

0x1 = 0001 b
0x3 = 0011 b
0x7 = 0111 b
0xF = 1111 b


Yes, try taking a simple for loop or while loop and doing the exact same
thing with if's and goto's, if you don't see it right away. Of course this
is very bad programming practice, since loops make your logic more much
clearer to the reader.

(If you're not totally familiar with loops in general, you might want to try
a higher-level language like Python/Java/C# before attempting C.)

Nah. I've written hundreds of for,while,until loops in sh.

Well "jump" is an assembly term for specific CPU instructions. Goto is the
equilavent in C. My point was that for and while loops compile down to
jumps and tests (instruction that return true or false, basically).


Good, I'm glad. This confirms an observation developed from some years of
teaching. Exactness isn't necessarily the problem, but you just have to
know WHAT you need to be exact about (i.e. not irrelevant details like
rarely used terminology).

Let me close with some more high level observations. What does C add on top
of this model (besides nice syntax, I'm talking ideas here)?

1) Platform independence -- instead of writing in native assembly, you write
in C, and then compilers for every platform translate your C program into a
stream of instructions (just byte data)

Good. That's an important piece of the puzzle.

2) Constructs like functions, for and while loops, if's and switches, to
organize this enormous stream of instructions

All of this is found in sh, some of it being called "flow control".

(except maybe "switches" do you mean options to the compiler/assembler?)

3) A strong type system -- this can be confusing at first

This is why I wanted to emphasize that pointers are just integers in
hardware. They're a C language construct. Same thing with characters/
character strings. Now floats ARE actually different in hardware, but we
won't get to that.
4) some other stuff which I don't care to think up now : )

The point of the type system is to catch mistakes at an obvious level.
Compiling a C program to see if all the types match up can catch a lot of
mistakes. It's sort of a sanity check, and it helps you structure your
program.

Don't really get that, but it *feels* important. Errr....Can you say
"feel" on a programming newsgroup?

But again, you can read all you want, but if you can pull off the exercise
with the debugger I suggested, you will learn a whole lot.

It'll happen.

Roose

Thank you again. Back to K&R and the Answer Book and I'll check out those
websites in due course.

Got really fed up with the Richard fellow. Killfiled his arrogant ass for
a while.

 

[Irrwahn Grausewitz]

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.

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.[/QUOTE]

You call Heathfield a troll? Bwhm. Bwhmhe. Bwhmhehehehe.
Bruahahahahahhaaaahahahahaahaaaaaahhaha <gasp> gnihihihihi.

You haven't been reading c.l.c for more than two days, have you?

 

[Irrwahn Grausewitz]

What Roose posted was very helpful to me.

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

You enjoy to be fed by an obvious troll? Happy proceedings.

 

[Irrwahn Grausewitz]

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

But he posted to the news-group. There is not much privacy in
usenet discussions, ya know?!?

<snip>

 

[Chris Torek]

... I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. ...

I would not call them "wildly different". The XBox uses an Intel
x86-type CPU as its main driver; the GameCube has a PowerPC CPU;
and the PS2 has a MIPS CPU. The latter two are traditional
register-oriented RISCs (although the PowerPC has a bizarre
instruction set, to anyone used to Intel and MIPS and even old IBM
370 assembly -- but not as bizarre as HP-PA or Itanium, if you ask
me). The Intel type CPU is common as dirt these days, of course.

Moreover, while game consoles do have specialized hardware (such
as special video RAM and "outboard" 3D transform engines), all
of these machines still have conventional linearly-addressed memory
for the CPUs to use, and the CPUs use it in conventional linear
fashion. And of course, all three of these are game consoles,
so they have the same ultimate goals, which results in remarkable
similarities of design.

For something really different, I would suggest trying these:

- Univac 11xx series: 18 and 36 bit integers, ones' complement
arithmetic. C compilers use 9-bit bytes.

- Data General Eclipse: conventional flat-memory RISC with one
twist: "byte pointers" (for char * and void *) are different
from all other, normal "word pointers". To convert a word
pointer to a byte pointer, the compiler must shift it left,
introducing a low-order zero bit.

- IBM AS/400. This is a "virtual architecture" with segmented,
protected memory. Pointers carry special qualification values
(a sort of access control list, as it were, or a "capability"
as it is usually called in other systems); pointers to code
are *much* larger than pointers to data.

One last architecture, for which I doubt there are any C compilers
(or even machines left? ), that can expand one's idea of how
to build computers, is the Burroughs A-series. There is a brief
(albeit a bit "gushy" ) overview at
<http://www.ajwm.net/amayer/papers/B5000.html>. (Many might quibble
with the claim that the Burroughs was the first machine to have
virtual memory, giving that honor instead to Manchester's Ferranti
Atlas.)

 

[Default User]

Alan Connor wrote:

[Richard Heathfield]

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

You are making a huge mistake. Richard is a frequent posters, a textbook
author and a well-respected member of this newsgroup.

Roose, on the other hand, is a troll who willing dispenses erroneous
information and replies with flames when challenged.

I suggest you reverse your decision. Killfile Roose, do not do the same
with Richard.




Brian Rodenborn

 

[Morris Dovey]

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.

Alan...

Wow! I'm impressed by your judgment. Richard has been one of the
most highly regarded regulars of comp.lang.c for some years now.
He's earned the professional (and personal) respect of many of
the best C programmers in the world, been recognized by Don Knuth
for spotting an error and providing a correction to "The Art of
Computer Programming", co-authored the book "C Unleashed" with
some of the most knowledgeable regulars here, and provided really
high-quality help to an awesome number of newbies (and a large
number of not-so-newbies, including myself) - all under the
scrutiny of expert peers who delight in picking nits - especially
when they're aware the poster /really/ knows his stuff.

I did say "impressed". I didn't say "favorably impressed". I
think I'd be honored if you called me deceitful and sophomoric
and a troll and killfiled me, too. I don't post as frequently as
Richard; but it /would/ save you at least some small amount of time.

 

[Default User]

What Roose posted was very helpful to me.

I'm not sure why you are so fascinated with Roose the Troll, but it's
not a good way to get good information in this newsgroup.

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

Irrwhan is a knowledgable and helpful member of this group. Roose is a
dispenser of bad information and a troll. I suggest reviewing the two
persons' posting history on this newsgroup via a visit to groups.google.




Brian Rodenborn

 

[August Derleth]

In college, I learned (to my later benefit) IBM 370 Assembly language.

Heh. I have an emulator for the System/360. It accepts batch jobs
(luckily, it doesn't take JCL) and returns a complete listing (a dump
if I've messed up).

Those old machines were rather interesting, especially where the
designers kind of knew what they really wanted but had to work around
the hardware to get something close.

Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language.

Heh. I guess the fact that Z80 assembly was binary-compatible with
8080 didn't help you much, then?

Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.

Then I guess you never learned the beauty that is VAX, I suppose?
More's the pity: Understanding some of the intricacies of the DEC
minicomputers can help you grasp why some of C's crucial early design
decisions were made the way they were. For example, a flat memory
model and the whole notion of pre[increment|decrement] being usefully
different from post[increment|decrement] both came directly from the
PDPs.

Truly, C was designed to be somewhere between PDP-11 assembly and
PL/1, but closer to assembly in some key ways.

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. ;-)

And I think learning PDP-8 assembly is what seperates the men from the
boys, esepcially if you can only use the 8 `actual' opcodes.

 

[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.

Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of course,
but I can assure you that I am not, nor have I ever been, a sophomore.

Killfiled for N days.

You have absolutely no idea how devastated I am to hear this.

I'm into saving time too.

The biggest win is to stop reading Usenet.

 

[CBFalconer]

.... snip ...

register int SomeThing;

as opposed to

int SomeThingElse;

Given
int *PointerToSomething;

you can
PointerToSomething = &SomeThingElse;
but not
PointerToSomething = &SomeThing;
because SomeThing is a register qualified object,
but SomeThingElse is not.

Which doesn't answer his question. The above is a penalty for
using register qualification, which actually means "I think this
variable would be better handled in a register". It is only a
suggestion, and the compiler need not pay any attention to it,
other than to enforce the above penalty. With modern optimizers
it is usually better not used.

 

[CBFalconer]

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

You have a basic misconception. He may think he is addressing
you, and you may think he is addressing you, but in reality he is
addressing the general public, as are you and I. He may also have
been addressing points you brought up. There is nothing private
about anything said here. Thus the cavils are needed to avoid
misinforming the larger audience.

So far your evaluation of the newsgroup participants appears to be
sadly flawed.

 

[Mark McIntyre]

Well, you just crossed the line with that bit of deceitful and sophomoric trolling.

Killfiled for N days.

I'm sorry, did you just killfile RJH?

I'm into saving time too.

well, killfiling the CLC regulars and gurus is certainly going to
achieve that. After a fashion.

 

[Mark McIntyre]

Mark: The limit for sigs on the Usenet is 4 lines and they need to be
immediately below a "-- " line.

I have no control over what alibis.com stick on after my sig, which is
three lines long.

Fix yours or I will have to killfile you.

Feel free.

What Newsfeed.Com is doing amounts to nothing but spam. Ditch them.

Its that or ntl's servers. Believe me, you don't want to use ntl's
news servers for more than about ten seconds.

By the way, are you also known as roose? I'm suspicious of your sudden
appearance in this thread, and your evident agreement with a troll.
Apologies if I'm maligining you but you see my point?

 

[Sheldon Simms]

Got really fed up with the Richard fellow. Killfiled his arrogant ass for
a while.

You are of course welcome to killfile anyone you want, however you
should be aware that Richard is telling you the truth and Roose is
not. At least, he is not telling you the whole truth.

For example, Roose said "a pointer is an integer". This is not
true. A pointer *might* be an integer, and it might be something
else, like two distinct integers, or something else entirely.

I understand that you might not see why it matters one way or
the other, but there is a good reason to be precisely correct
right from the start: it prevents you from making lazy assumptions
that might not bite you now, but that probably will bite you
later.

I don't know why you are learning C, but lets imagine that you
might someday want to program professionally using C. If so, you
might find it professionally embarrassing when your code crashes
the airplane, cash register, medical device, file server, robot,
etc. because you assumed that a pointer is "just an integer",
as Roose urged you to.

Perhaps you think that's just hypothetical, that you'll worry
about the details when you know C better. Well that might work,
but on the other hand, I have seen things like that happen
(well, nothing as dramatic as a plane crash) because the
programmer didn't *really* know how C worked.

-Sheldon

 

[BruceS]

Alan Connor wrote:

Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of course,
but I can assure you that I am not, nor have I ever been, a sophomore.

OK, I for one have been getting a good laugh at your exchanges with Roose,
but this bit surprises me. Is it a British thing, or have you really never
been in the second year of secondary school or college? EMWTK.

<snip>