F
R
Richard Bos
I think you should get the distinction between zero and null clear, and
learn not to invoke undefined behaviour, before you start teaching
others about pointers.
Richard
F
Foobarius Frobinium
Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
A
Arthur J. O'Dwyer
The second example on the page, which is also the place you confuse
"zero" and "null." And again in the fourth example. Maybe some
other places; I just skimmed to find the things Richard must have been
referring to.
-Arthur
R
Richard Bos
The issue I was mainly referring to has come up so bloody often on this
newsgroup, that if you'd ever read it for comprehension you'd have know
_exactly_ what I was talking about. Since I don't think that someone
incompetent should be teaching others on the use of pointers (because
it's too bloody dangerous), that's all the help you will get from me.
Richard
F
Foobarius Frobinium
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.)
Dangerous? Is somebody going to lose a leg?
M
Michael Mair
Foobarius said:
And why exactly do you want to be counted among the ranks of
the incompetent and dangerously stupid?
Learn from Richard's comments, mend your ways and the misinformation
you spread.
I see a certain danger in having the least qualified candidates teach
the next generations.
Apart from that:
It may not have occurred to you yet, but some of the people you
teach one day may work on real life applications. And there,
UB may creep in at the most inconvenient place and strike when
lives or inviolacy depend on what some piece of software does or
did. I certainly would not find it merely inconvenient if I produced
some wrong simulation results causing a structural weakness in a
vehicle which is only exhibited in situations which have not been
tested, for example.
And, having seen more then one one-week-course-too-teach-you-all
with all its minor and major errors, this is a possibility.
-Michael
F
Foobarius Frobinium
Arthur J. O'Dwyer said:
I did fix the NULL bit; yes that was pretty bad.
But I can't help but take offense when I come to an NG, not wanting to
cause trouble, and I get a completely uncalled-for brow-beating from
someone, who in this case is one Mr. Vos.
Failing to adhere to a certain feature of the C standard does not
deserve anything more than a kind correction. I taught myself
everything I know about C and pointers, taking special pains to pull
together various bits of frequently incorrect documentation both in
books and on the web (the C FAQ was especially useful), and I'm just
trying to help others. I wouldn't say I'm a C expert; I haven't even
graduated high school yet. I intend to divulge what I've learned in a
comprehensive format. In the process, I merely ask for a little
assistance, not for someone else to bend over backwards, and it seems
I won't get any.
Hence I implore everyone on this NG to behave a little more
respectfully, and remember there /is/ a real person on the other side
of the news server.
A
Alan Balmer
The above remarks by Mr. Bos hardly qualify as browbeating. You
present yourself as someone qualified to teach others about pointers,
and must expect that folks in this group won't let you get away with
inaccuracies.
A
Alan Balmer
How would you know that, not having even graduated high school yet?
It could be far worse than that. I worked for twenty years in an
industry where a program's undefined behavior can (and sometimes does)
kill people.
M
Mike Wahler
Foobarius Frobinium said:
Yes, most of us are well aware of the plethora of incompetent
instructors out there. We don't need any more of them, or anyone
else helping to spread their misinformation. We do our best to
minimize the damage they cause.
Yes, there is a very real possibility that could happen as
the result of a software failure (I suspect that that, and
worse, has already occurred).
-Mike
E
Eric Sosman
Foobarius said:
If you don't think software faults can be dangerous,
Google for "Therac-25." True, the bug wasn't a pointer
problem -- but it *killed* people, as in stone-cold dead.
It could even be argued that the problem wasn't a "bug;"
the code was probably "good enough" for its original
purpose and only became dangerous when re-used in a less
forgiving context -- but in any event, the victims are
not in a position to give us their insights.
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.
O
Old Wolf
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
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.
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 segment
ffset addresseseverywhere in your examples, so that it is clear that ints
and pointers are NOT interchangeable.
Also, all of your examples with malloc() have undefined
behaviour. Read the FAQ on how to invoke malloc properly.
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).
F
Foobarius Frobinium
Alan Balmer said:
A lot of my friends are adults, in Computer Science, who told me about
this. Plus I've /seen/, here and there, parts of CS courses published
on the web where that kind of error occurs. It's a little depressing
to be honest with you.
Anyways, I agree that NULL != 0, and I made the changes in five
minutes with vi.
Well, then, for safety's sake, we'd better get moving! For the sake of
curiousity, what languages does an embedded device usually use? (I
usually hear of a small Scheme dialect, C, or ugh...Java)
F
Foobarius Frobinium
Alan Balmer said:
The saying goes: don't look down on someone unless you are helping
them up. (usually attributed to MLK Jr.) If you aren't going to help
someone up, don't complain about their alleged incompetence (see
elsewhere in the thread).
Yes, and this is why I submitted the guide for review in the first
place. The first drafts had some issues, and I weeded them out,
resulting in a better document each time. And each time I submitted
it, I had less complaints even from the most critical readers. Even if
the criticisms are rudely delivered, I always take them into account,
and make changes according to them.
F
Foobarius Frobinium
Michael Mair said:
I did. As said, I will take even rude criticisms into account. Read
the guide again: :s/0/NULL/g, plus a little explanation of what the
NULL macro is for.
Read the bottom of this:
http://vergil.chemistry.gatech.edu/resources/programming/c-tutorial/arrays.html
Are you sure the term '**least** qualified' applies to me? I'm not
going to suggest that I am the absolute best, but I think it's fair to
say I fall somewhere into the middle. And that's a COLLEGE programming
course.
<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.
- Shimon
A
Alan Balmer
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 ;-)
A
Alan Balmer
An interesting question, of course, though I wasn't speaking of
embedded systems, but process control. You might want to poke around
the archives for comp.arch.embedded. Many embedded systems are written
in C or assembler.
M
Michael Mair
Foobarius said:
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.
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.
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.
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.
Fair enough.
I suggest we end this thread of the discussion.
Good Luck
Michael
R
Richard Bos
Even that is bunkum. NULL isn't a pointer. The most likely value of NULL
is 48.
Richard