Pointer Guide Nearing Completion

[Richard Bos]

Then you'd better get working, going around to all those universities
and colleges where the CS professors confuse arrays and
pointers...their infractions are far worse. (And there's plenty of
them.)

_Their_ incompetence is not _your_ excuse.

Dangerous? Is somebody going to lose a leg?

Possibly, yes.

Richard

 

[CBFalconer]

You don't realize when you are being helped. Richard went
directly to the heart of the matter.


Why not? One can recognize and comment on shortcomings without having
the expertise or desire to take on an apprentice. For professional
people, merely pointing to a defect is often enough - they are quite
capable of rectifying it through their own efforts.

If everyone adopted your proposal, no one could complain about the
weather, or the government, (or Richard, for that matter ;-)

Or we would be extolling the praises of BullSchildt. Weather
complaints often follow the sunspot cycle. Government complaints,
OTOH, seem to be highly localized, and can generate the highest
levels of vituperation.

 

[CBFalconer]

<snip>

The reason I submitted the guide for review was because I wanted
it to be accurate. I knew full well, this being Usenet after all,
someone would go a little too far. But I /do/ care, and I /do/
listen, in spite of anything else.

Actually such a thing is quite valuable. The person who is most
aware of the pitfalls of a particular subject is the one who has
just learned that subject. Therefore he is capable of an
exposition that covers those pitfalls. Unfortunately he has
usually not learned everything, nor will he, and so all expositions
have holes at which to pick.

The problem is how much to cavil.

 

[Foobarius Frobinium]

(e-mail address removed) (Old Wolf) wrote in message

It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.

Ok, then let me qualify that, as per the C FAQ: it does not point to any
object or function. For all practical purposes, it points to nothing.
Semantic disgressions are a tad petty I would think. (On the other hand,
I should note that NULL can represent an uninitialized value, such as
the NULL link at the end of a list)

You imply (even if unintentionally) that NULL might be something
other than 0. The only reason to write NULL instead of (void *)0
is clarity; safety does not come into it. NULL _must_ be the
integer 0 , optionally cast to a pointer type.

You're right.

This confusion is compounded by the fact that you use ints
for addresses in your code. The reader may well end up thinking
that (void *)0 means address 0, you do not have any text that
educates him otherwise. I suggest using segmentffset addresses
everywhere in your examples, so that it is clear that ints
and pointers are NOT interchangeable.

Of course I do, right in the introduction. I even attributed that
development to Konrad Zuse to liven up the dry material. I will,
however, instruct the reader that ints and pointers are not freely
convertible.

Also, all of your examples with malloc() have undefined
behaviour. Read the FAQ on how to invoke malloc properly.

I wgot the C FAQ from eskimo, and grepped for all instances of malloc. I
assume you're saying I shouldn't cast the return value.

There is no such word "casted" and your explanation of
the cast is very poor. (Needless to say, you should omit
the cast entirely, and probably omit any discussion of
the return type of malloc).

- Shimon

 

[Foobarius Frobinium]

The obvious issues already have been pointed out, also the issues with
your corrections.
I reacted to your response to Richard's justified comments which seemed
to imply --without the context of your later posts-- that you tended to
be incorrigible.

Listen, if you will. I think we can just point out errors without
ascribing things like 'incompetent' to the original poster. That's
just how I do things.

If I were so incompetent, the CEO of Penn State would probably not
want to talk to me mono a mono, nor would I have spirited
conversations with philosophy professors.

Umh, which part of
| * Arrays are, in simple terms, just a pointer! Remember that!
| * There isn't much to review. Remember arrays have limitations
| because they are inherently just a pointer. Wait we mentioned
| that already.
|
|Pointers :: Arrays :: Dynamic Memory Allocation
|Table of Contents
|© 1999-2001 The Sherrill Group
|Georgia Institute of Technology
|Document author: Alfred Park
|Questions, suggestions, comments? E-mail the Webmaster.
|Last Modified: July 3, 2001
should tell me about your qualification?
However, This comment is to be seen in context with your above comments
seeming to imply that there are much worse instructors around because of
which you were not ready to mend your ways.

No, it's not /their/ fault. I busted my hump learning this, but it
doesn't make it their fault. I am just saying the behavior should be
consistent with respect to teaching pointers if it is indeed truly
dangerous. And above, I'm talking in relative terms. Someone called me
'least qualified', which to me means, absolute bottom of the barrel.
Like I said, I'm in the middle.

Whoever is teaching should be aware that if he/she is doing it for the
first five times for a given subject then he/she is probably the party
who has to learn more and will learn more if willing than the students.
Anyone who says or implies that he or she needs to learn or change no
more is in my eyes not very well-qualified.

Of course. Then he or she falls into the 'authority' category.

Your later responses in this thread show a different disposition.
About your actual qualification I cannot say anything without having
seen real code of yours and having asked some of my pet questions in a
one-on-one interview.

I have some stuff in CVS but mostly I work with Perl.

<snip>

I have a few more things to wrap up in this thread.

 

[Foobarius Frobinium]

If everyone adopted your proposal, no one could complain about the
weather, or the government, (or Richard, for that matter ;-)

A man greater than probably any of us said that. Yeah, it would be
hard to live up to that.

 

[Thomas Stegen]

Listen, if you will. I think we can just point out errors without
ascribing things like 'incompetent' to the original poster. That's
just how I do things.

If I were so incompetent, the CEO of Penn State would probably not
want to talk to me mono a mono, nor would I have spirited
conversations with philosophy professors.

Looky here. People on usenet often has many usefult things to say.
They are also very inclined to spice it up with insults at the same
time. Listen to their advice and ignore the rest. Set up a bullshit
filter and glean out the useful information. There is a lot of both
coming out of usenet.

Since being insulted on usenet will not affect you in the real world
unless you yourself take it there and insulting back on usenet just
lowers people regard for you, my best advice is to just don't. If you
have to, raise a protest once for the archives and then just let it
go wherever it goes. You will be in the clear.

If you keep up this work, your pointer guide will be good, if not great,
eventually, and it is already resembling a useful resource. A few more
rounds of review here will get it there. Just remember to set
appropriate mental filters.

 

[Thomas Stegen]

(e-mail address removed) (Old Wolf) wrote in message



I wgot the C FAQ from eskimo, and grepped for all instances of malloc. I
assume you're saying I shouldn't cast the return value.

The cast is not problem (though it is an issue). The problem
is your failure to include stdlib.h.

Interestingly enough, your compiler would have warned you about
this had you _not_ included the case. Case in point I think, and
a very relevant argument for not casting the value of malloc.

 

[Thomas Stegen]

Do computer curricula nowadays include the tale of
the Therac, or other sobering stories? Seems to me it'd
be a good idea if they did.

For my degree everyone got to hear about the Ariane 5 accident.
For one of my electives we also got the Therac, the london
ambulance service and a few others.

So, at least some do.

 

[Alan Balmer]

I should note that NULL can represent an uninitialized value, such as
the NULL link at the end of a list)

No. Unitialized != NULL. If you want your list processing code to
work, you had better set that link to NULL explicitly.

 

[Dave Vandervies]

(e-mail address removed) (Old Wolf) wrote in message


Ok, then let me qualify that, as per the C FAQ: it does not point to any
object or function. For all practical purposes, it points to nothing.
Semantic disgressions are a tad petty I would think.

"Semantic disgressions" of this sort are a matter of saying what you
mean and meaning what you say. If you consider that petty, then perhaps
computer programming is a bad career choice; computers tend to expect
it of you all the time.


dave

 

[Foobarius Frobinium]

Looky here. People on usenet often has many usefult things to say.
They are also very inclined to spice it up with insults at the same
time. Listen to their advice and ignore the rest. Set up a bullshit
filter and glean out the useful information. There is a lot of both
coming out of usenet.
True.

Since being insulted on usenet will not affect you in the real world
unless you yourself take it there and insulting back on usenet just
lowers people regard for you, my best advice is to just don't.

I agree wholeheartedly. I used to be a big flamer, but I realized
that: misunderstandings (usually because text does not convey mood)
happen and even otherwise, it's just not worth it to get down to that
level.

If you
have to, raise a protest once for the archives and then just let it
go wherever it goes. You will be in the clear.

If you keep up this work, your pointer guide will be good, if not great,
eventually, and it is already resembling a useful resource.

Thx, dude!!

 

[Foobarius Frobinium]

_Their_ incompetence is not _your_ excuse.

I would not suggest that. I'm merely asking for consistency. And when
I struggle by myself to learn damn near everything (C pointers, Perl
typeglobs, fvwm2, and pretty much anything I know about *Nix,
programming, and computers in general), I would appreciate a little
help now and then.

 

[Foobarius Frobinium]

No. Unitialized != NULL. If you want your list processing code to
work, you had better set that link to NULL explicitly.

That's what I meant. Of course such things will crop up; one of my
initial problems was that I used the Deep C Secrets definition of
lvalue and rvalue. Someone lashed out at me nasty that time!!

Would you suggest that I liken NULL in a list to '\0' in a string?

 

[Arthur J. O'Dwyer]

That's what I meant.

I think most of us (including Alan) knew what you meant, but your
wording could have been misleading. Perhaps you could say that "the value
NULL is often used to indicate a pointer which is 'intentionally left
blank,' as in the last link in a linked list."

Would you suggest that I liken NULL in a list to '\0' in a string?

No. Because the C Standard explicitly canonizes the use of '\0' to mean
"end of a string," but there is no aspect of standard C in which NULL
means "end of a list." The routines in <stdlib.h> deal only with arrays
with explicit lengths.

Abstractly, yes, the "end of list" marker NULL and the "end of char
array" marker '\0' are very similar. But I suggest you don't liken NULL
to '\0' in a tutorial for learners of C, because that comparison would
cause more confusion than it would defuse.

-Arthur

 

[Foobarius Frobinium]

"Semantic disgressions" of this sort are a matter of saying what you
mean and meaning what you say. If you consider that petty, then perhaps
computer programming is a bad career choice; computers tend to expect
it of you all the time.

I know what computers expect from their operators. Here we are talking
more about general abstract thinking than programming as such...the
difference between 'points at nothing' and 'does not point at
anything' probably will not be discerned by computers for /some time/.
For our purposes, they are virtually the same, as neither & nor a
successful call to malloc will ever return NULL.

 

[Richard Bos]

I think most of us (including Alan) knew what you meant, but your
wording could have been misleading.

And that's the real problem. _We_ know what he meant. However, we are
not the kind of person to read a pointer guide - not any more, that is.
Pointer guides, or any other kind of guides, are written to aid those
who do not yet know much about the subject. This means that the audience
cannot read between the lines, and that means that the guide must be
correct - it cannot rely on the reader mentally correcting inaccuracies.

Richard

 

[Richard Bos]

I would not suggest that. I'm merely asking for consistency.

I _am_ consistent - if one of those other pointer guide writers came
here and asked for comments, they'd get chewed out just as badly.

Richard

 

[Foobarius Frobinium]

I _am_ consistent - if one of those other pointer guide writers came
here and asked for comments, they'd get chewed out just as badly.

Well, that's all right. You are not the only other person on this
NG...feel free to rant and flame as much as you please, because you
are by no means a bottleneck in my progress, a diversion at most.

Moreover, if you are so nasty to others on Usenet (as well as in
public, if you /would/ do the same in public), you will be rewarded
commensurately.

Cheers,
Shimon

 

[Foobarius Frobinium]

Even that is bunkum. NULL isn't a pointer. The most likely value of NULL
is 48.

That's unusual...it disagrees with 5.10 in C FAQ, which says NULL is a
stylistic convention, and guarantees 0's to be null pointers.

Just out of curiousity, why would NULL be defined as 48?