48  2320 
On Wed, 20 Oct 2004, Foobarius Frobinium wrote:
Richard Bos wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote:
http://thelinuxlink.net/~fingolfin/pointer-guide
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.
Where do I invoke undefined behavior, besides the part marked
/* ERROR!! */??
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 fo******@youremailbox.com (Foobarius Frobinium) wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
http://thelinuxlink.net/~fingolfin/pointer-guide
Tell me what you think...
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.
Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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 rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
> http://thelinuxlink.net/~fingolfin/pointer-guide
>
> Tell me what you think...
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.
Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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?
that's all the help you will get from me.
Richard
Foobarius Frobinium wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...fo******@youremailbox.com (Foobarius Frobinium) wrote:rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
fo******@youremailbox.com (Foobarius Frobinium) wrote:
>http://thelinuxlink.net/~fingolfin/pointer-guide
>
>Tell me what you think...
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.
Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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.)
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.
Dangerous? Is somebody going to lose a leg?
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
--
E-Mail: Mine is a gmx dot de address.
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix40. andrew.cmu.edu>... On Wed, 20 Oct 2004, Foobarius Frobinium wrote:
Richard Bos wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote:
http://thelinuxlink.net/~fingolfin/pointer-guide
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.
Where do I invoke undefined behavior, besides the part marked
/* ERROR!! */??
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.
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.
-Arthur
On 21 Oct 2004 06:59:49 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix40. andrew.cmu.edu>... On Wed, 20 Oct 2004, Foobarius Frobinium wrote: >
> Richard Bos wrote:
>> fo******@youremailbox.com (Foobarius Frobinium) wrote:
>>>
>>> http://thelinuxlink.net/~fingolfin/pointer-guide
>>
>> 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.
>
> Where do I invoke undefined behavior, besides the part marked
> /* ERROR!! */??
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.
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.
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.
--
Al Balmer
Balmer Consulting re************************@att.net
On 21 Oct 2004 04:50:25 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
> rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
> > fo******@youremailbox.com (Foobarius Frobinium) wrote:
> >
> > > http://thelinuxlink.net/~fingolfin/pointer-guide
> > >
> > > Tell me what you think...
> >
> > 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.
>
> Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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.)
How would you know that, not having even graduated high school yet?
Dangerous? Is somebody going to lose a leg?
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.
--
Al Balmer
Balmer Consulting re************************@att.net
"Foobarius Frobinium" <fo******@youremailbox.com> wrote in message
news:a7**************************@posting.google.c om... rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message
news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message
news:<41***************@news.individual.net>... 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),
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.)
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.
Dangerous? Is somebody going to lose a leg?
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
Foobarius Frobinium wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
[...]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),
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?
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.
-- Er*********@sun.com fo******@youremailbox.com (Foobarius Frobinium) wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: On Wed, 20 Oct 2004, Foobarius Frobinium wrote:> fo******@youremailbox.com (Foobarius Frobinium) wrote:
Where do I invoke undefined behavior, besides the part marked
/* ERROR!! */??
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.
I did fix the NULL bit; yes that was pretty bad.
It still isn't fixed. You wrote:
NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
usually it is (void *) 0. (The void pointer is explained below.)
Usually, NULL is a void pointer to address 0, but, it's best to
use the NULL definition, just to be safe and for clarity.
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:offset addresses
everywhere 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).
Alan Balmer <al******@att.net> wrote in message news:<6h********************************@4ax.com>. .. On 21 Oct 2004 04:50:25 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
> rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
> > fo******@youremailbox.com (Foobarius Frobinium) wrote:
> >
> > > http://thelinuxlink.net/~fingolfin/pointer-guide
> > >
> > > Tell me what you think...
> >
> > 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.
>
> Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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.)
How would you know that, not having even graduated high school yet?
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.
Dangerous? Is somebody going to lose a leg?
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.
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)
Alan Balmer <al******@att.net> wrote in message news:<o8********************************@4ax.com>. .. On 21 Oct 2004 06:59:49 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix40. andrew.cmu.edu>... On Wed, 20 Oct 2004, Foobarius Frobinium wrote:
>
> Richard Bos wrote:
>> fo******@youremailbox.com (Foobarius Frobinium) wrote:
>>>
>>> http://thelinuxlink.net/~fingolfin/pointer-guide
>>
>> 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.
>
> Where do I invoke undefined behavior, besides the part marked
> /* ERROR!! */??
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.
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.
The above remarks by Mr. Bos hardly qualify as browbeating.
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).
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.
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.
Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>... Foobarius Frobinium wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...fo******@youremailbox.com (Foobarius Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
>fo******@youremailbox.com (Foobarius Frobinium) wrote:
>
>>http://thelinuxlink.net/~fingolfin/pointer-guide
>>
>>Tell me what you think...
>
>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.
Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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.)
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 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.
Dangerous? Is somebody going to lose a leg?
I see a certain danger in having the least qualified candidates teach
the next generations.
Read the bottom of this: http://vergil.chemistry.gatech.edu/r...al/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
On 21 Oct 2004 16:04:19 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote: The above remarks by Mr. Bos hardly qualify as browbeating.
The saying goes: don't look down on someone unless you are helping
them up. (usually attributed to MLK Jr.)
You don't realize when you are being helped. Richard went directly to
the heart of the matter.
If you aren't going to help
someone up, don't complain about their alleged incompetence (see
elsewhere in the thread).
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 ;-)
--
Al Balmer
Balmer Consulting re************************@att.net
On 21 Oct 2004 15:58:55 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote: Alan Balmer <al******@att.net> wrote in message news:<6h********************************@4ax.com>. .. On 21 Oct 2004 04:50:25 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote:
<snip> >Dangerous? Is somebody going to lose a leg?
>
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.
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)
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.
--
Al Balmer
Balmer Consulting re************************@att.net
Foobarius Frobinium wrote: Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>...
Foobarius Frobinium wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
fo******@youremailbox.com (Foobarius Frobinium) wrote:
>rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
>
>>fo******@youremailbox.com (Foobarius Frobinium) wrote:
>>
>>
>>>http://thelinuxlink.net/~fingolfin/pointer-guide
>>>
>>>Tell me what you think...
>>
>>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.
>
>Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
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),
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.)
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 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.
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.
Dangerous? Is somebody going to lose a leg?
I see a certain danger in having the least qualified candidates teach
the next generations.
Read the bottom of this:
http://vergil.chemistry.gatech.edu/r...al/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.
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.
<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.
Fair enough.
I suggest we end this thread of the discussion.
Good Luck
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address. ol*****@inspire.net.nz (Old Wolf) wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote: I did fix the NULL bit; yes that was pretty bad.
It still isn't fixed. You wrote:
NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
Even that is bunkum. NULL isn't a pointer. The most likely value of NULL
is 48.
Richard fo******@youremailbox.com (Foobarius Frobinium) wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... 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),
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
Alan Balmer wrote: (Foobarius Frobinium) wrote:
The above remarks by Mr. Bos hardly qualify as browbeating.
The saying goes: don't look down on someone unless you are
helping them up. (usually attributed to MLK Jr.)
You don't realize when you are being helped. Richard went
directly to the heart of the matter.
If you aren't going to help someone up, don't complain about their
alleged incompetence (see elsewhere in the thread).
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.
--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan" - "I listened to Toronto come back
from 3:0 in '42, I watched Boston come back from 3:0 in '04"
Foobarius Frobinium wrote:
<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.
--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan" - "I listened to Toronto come back
from 3:0 in '42, I watched Boston come back from 3:0 in '04" ol*****@inspire.net.nz (Old Wolf) wrote in message
news:<84************************@posting.google.co m>... fo******@youremailbox.com (Foobarius Frobinium) wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: On Wed, 20 Oct 2004, Foobarius Frobinium wrote:
>> fo******@youremailbox.com (Foobarius Frobinium) wrote:
>
> Where do I invoke undefined behavior, besides the part marked
> /* ERROR!! */??
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.
I did fix the NULL bit; yes that was pretty bad.
It still isn't fixed. You wrote:
NULL is defined by your C compiler as a pointer to nothing;
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)
usually it is (void *) 0. (The void pointer is explained below.)
Usually, NULL is a void pointer to address 0, but, it's best to
use the NULL definition, just to be safe and for clarity.
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 segment:offset 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
Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>... Foobarius Frobinium wrote: Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>...
Foobarius Frobinium wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
>fo******@youremailbox.com (Foobarius Frobinium) wrote:
>
>>rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41***************@news.individual.net>...
>>
>>>fo******@youremailbox.com (Foobarius Frobinium) wrote:
>>>
>>>
>>>>http://thelinuxlink.net/~fingolfin/pointer-guide
>>>>
>>>>Tell me what you think...
>>>
>>>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.
>>
>>Where do I invoke undefined behavior, besides the part marked /* ERROR!! */??
>
>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),
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.)
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 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.
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.
Dangerous? Is somebody going to lose a leg?
I see a certain danger in having the least qualified candidates teach
the next generations.
Read the bottom of this:
http://vergil.chemistry.gatech.edu/r...al/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.
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.
Alan Balmer <al******@att.net> wrote in message news:<41********************************@4ax.com>. ..
<snip> 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.
Foobarius Frobinium wrote: Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>... 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.
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.
Foobarius Frobinium wrote: ol*****@inspire.net.nz (Old Wolf) wrote in message
news:<84************************@posting.google.co m>... 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.
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.
Eric Sosman wrote: 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.
--
Thomas.
On 22 Oct 2004 06:48:15 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote: 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.
--
Al Balmer
Balmer Consulting re************************@att.net
In article <a7**************************@posting.google.com >,
Foobarius Frobinium <fo******@youremailbox.com> wrote: ol*****@inspire.net.nz (Old Wolf) wrote in message
news:<84************************@posting.google.c om>... 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.
"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
--
Dave Vandervies dj******@csclub.uwaterloo.ca
There is no possible way that CHAR_MIN can be 255, and certainly no way
that CHAR_MIN can exceed 255.
--Ben Pfaff in comp.lang.c
Thomas Stegen <th***********@gmail.com> wrote in message news:<2t*************@uni-berlin.de>... Foobarius Frobinium wrote: Michael Mair <Mi**********@invalid.invalid> wrote in message news:<2t*************@uni-berlin.de>...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.
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!!
A few more
rounds of review here will get it there. Just remember to set
appropriate mental filters. rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... 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),
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.
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.
Alan Balmer <al******@att.net> wrote in message news:<ag********************************@4ax.com>. .. On 22 Oct 2004 06:48:15 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote:
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.
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?
On Sat, 23 Oct 2004, Foobarius Frobinium wrote:
Alan Balmer <al******@att.net> wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote: I should note that NULL can represent an uninitialized value, such as
the NULL link at the end of a list)
No. Uninitialized != NULL. If you want your list processing code to
work, you had better set that link to NULL explicitly.
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 dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote in message news:<cl**********@rumours.uwaterloo.ca>... In article <a7**************************@posting.google.com >,
Foobarius Frobinium <fo******@youremailbox.com> wrote:ol*****@inspire.net.nz (Old Wolf) wrote in message
news:<84************************@posting.google.c om>... 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.
"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.
dave
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: On Sat, 23 Oct 2004, Foobarius Frobinium wrote: That's what I meant.
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 fo******@youremailbox.com (Foobarius Frobinium) wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... fo******@youremailbox.com (Foobarius Frobinium) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
> 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),
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.
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 rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... 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 rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>... ol*****@inspire.net.nz (Old Wolf) wrote:
fo******@youremailbox.com (Foobarius Frobinium) wrote: I did fix the NULL bit; yes that was pretty bad.
It still isn't fixed. You wrote:
NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
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?
Richard
Foobarius Frobinium wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
ol*****@inspire.net.nz (Old Wolf) wrote:
fo******@youremailbox.com (Foobarius Frobinium) wrote:
I did fix the NULL bit; yes that was pretty bad.
It still isn't fixed. You wrote:
NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
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.
^^^^^^^^^^^^^^^^^^^^^^^
What Richard probably is referring to is the fact that neither
NULL nor 0 are _pointers_ but are interpreted as a null pointer
constant. 0, as it is, is an integer value. If this is converted into a
pointer, anything can happen to the actual value of the pointer.
That means
int i, ptr=NULL;
unsigned char *rep;
rep=&ptr;
for (i=0; i<sizeof ptr; i++)
printf("%x\n",(unsigned int) (*rep++));
will not necessarily give you
0x0
0x0
....
So, what I marked above, is *wrong*.
Just out of curiousity, why would NULL be defined as 48?
NULL is never defined as 48 but the actual representation of
a "pointer that does not point anywhere" is not necessarily 0.
If it is a valid address that is during runtime interpreted
as null pointer, it is not necessarily "byte zero" or "segment:offset
with offset 0".
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address. rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote: ol*****@inspire.net.nz (Old Wolf) wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote: NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
Even that is bunkum. NULL isn't a pointer.
Argh.
"A null pointer is a pointer that doesn't point anywhere."
"NULL is a null pointer constant."
"When a null pointer constant is converted to a pointer type,
the result is a null pointer."
Happy?
The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om... rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote: ol*****@inspire.net.nz (Old Wolf) wrote: fo******@youremailbox.com (Foobarius Frobinium) wrote:
> NULL is defined by your C compiler as a pointer to nothing;
It is a pointer that doesn't point anywhere. There is no 'nothing'
that it points to.
Even that is bunkum. NULL isn't a pointer.
Argh.
"A null pointer is a pointer that doesn't point anywhere."
"NULL is a null pointer constant."
"When a null pointer constant is converted to a pointer type,
the result is a null pointer."
Happy?
The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
Couldn't a pointer to a zero that is called NULL reside at address 48 in
memory, thereby making NULL have a "value" of 48? ;-) Just asking...
--
Mabden
In article <84**************************@posting.google.com >, ol*****@inspire.net.nz (Old Wolf) writes: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
One of the permissible values of the NULL macro is 0 - a character
from the source character set. NULL is expanded during translation
phase 4. Its immediate value, then, is not binary 0, but some
sequence of pp- tokens in the source character set. If the source
character set happens to be ASCII, or to use the same code point as
ASCII for the '0' character, and NULL is defined simply as that
character, then in a sense the "value" of NULL is a single char with
binary value 48 (the code point of '0' in ASCII).
If you hypothesize, then, that a majority of implementations use
ASCII and define NULL as 0, you might say the value of NULL is 48.
Or you might not. Clearly NULL has various "values" at various
stages of translation, and in various conceptual domains, and I don't
see a strong argument for declaring any of them the "real value" of
NULL.
It was a clever bit on Richard's part, though.
--
Michael Wojcik mi************@microfocus.com
Pseudoscientific Nonsense Quote o' the Day:
From the scientific standpoint, until these energies are directly
sensed by the evolving perceptions of the individual, via the right
brain, inner-conscious, intuitive faculties, scientists will never
grasp the true workings of the universe's ubiquitous computer system.
-- Noel Huntley mw*****@newsguy.com (Michael Wojcik) wrote: In article <84**************************@posting.google.com >, ol*****@inspire.net.nz (Old Wolf) writes: rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
One of the permissible values of the NULL macro is 0 - a character
from the source character set. NULL is expanded during translation
phase 4. Its immediate value, then, is not binary 0, but some
sequence of pp- tokens in the source character set. If the source
character set happens to be ASCII, or to use the same code point as
ASCII for the '0' character, and NULL is defined simply as that
character, then in a sense the "value" of NULL is a single char with
binary value 48 (the code point of '0' in ASCII).
If you hypothesize, then, that a majority of implementations use
ASCII and define NULL as 0, you might say the value of NULL is 48.
Bingo.
Or you might not. Clearly NULL has various "values" at various
stages of translation, and in various conceptual domains, and I don't
see a strong argument for declaring any of them the "real value" of
NULL.
True, but my main point was that NULL is not a pointer, neither a
pointer object nor a pointer value, but a macro. A bit of text in your
source code. Null pointers point at no object; a null pointer constant
does not point. Confusion between null pointers and null pointer
constants is probably the greatest cause of problems people have with
null pointers.
Richard
In article <41****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: mw*****@newsguy.com (Michael Wojcik) wrote:
Clearly NULL has various "values" at various
stages of translation, and in various conceptual domains, and I don't
see a strong argument for declaring any of them the "real value" of
NULL.
True, but my main point was that NULL is not a pointer, neither a
pointer object nor a pointer value, but a macro. A bit of text in your
source code. Null pointers point at no object; a null pointer constant
does not point. Confusion between null pointers and null pointer
constants is probably the greatest cause of problems people have with
null pointers.
Oh, I agree, which is one of the reasons why I called it a clever
bit. Certainly it'd be a way for newbies to remember the differences
among NULL, null pointer constants, and null pointers. If they say
to themselves "a common value for NULL is 48", then take a moment to
remember in what context that's true, that would probably make a fine
mnemonic device for the whole concept.
--
Michael Wojcik mi************@microfocus.com
Although he was an outsider, and excluded from their rites, they were
always particularly charming to him at this time; he and his household
received small courtesies and presents, just because he was outside.
-- E M Forster
"Mabden" <mabden@sbc_global.net> wrote in message
news:I9***************@newssvr13.news.prodigy.com. .. "Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om... rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote: ol*****@inspire.net.nz (Old Wolf) wrote:
> fo******@youremailbox.com (Foobarius Frobinium) wrote:
> > NULL is defined by your C compiler as a pointer to nothing;
>
> It is a pointer that doesn't point anywhere. There is no 'nothing'
> that it points to.
Even that is bunkum. NULL isn't a pointer.
Argh.
"A null pointer is a pointer that doesn't point anywhere."
"NULL is a null pointer constant."
"When a null pointer constant is converted to a pointer type,
the result is a null pointer."
Happy?
The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
Couldn't a pointer to a zero that is called NULL reside at address 48 in
memory, thereby making NULL have a "value" of 48? ;-) Just asking...
The value of a pointer and the value of the object to which
it points (if any), are distinct.
int i = 42; /* the value of 'i' is 42 */
int *p = &i; /* the value of 'p' is *NOT* 42 */
/* the value of 'p' is the memory address of 'i' */
The value of NULL is zero, or zero converted to type 'void*'.
The value of a pointer object after having NULL assigned to it is
"null pointer". This might or might not corresponding to a bit
pattern of all zeros, or the binary value of 48, or ... etc.
-Mike
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:ts****************@newsread3.news.pas.earthli nk.net...
"Mabden" <mabden@sbc_global.net> wrote in message
news:I9***************@newssvr13.news.prodigy.com. .. "Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om... rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> ol*****@inspire.net.nz (Old Wolf) wrote:
> > fo******@youremailbox.com (Foobarius Frobinium) wrote:
>
> > > NULL is defined by your C compiler as a pointer to nothing;
> >
> > It is a pointer that doesn't point anywhere. There is no
'nothing' > > that it points to.
>
> Even that is bunkum. NULL isn't a pointer.
Argh.
"A null pointer is a pointer that doesn't point anywhere."
"NULL is a null pointer constant."
"When a null pointer constant is converted to a pointer type,
the result is a null pointer."
Happy?
>The most likely value of NULL is 48.
I don't see how NULL can have a value of 48.
Couldn't a pointer to a zero that is called NULL reside at address
48 in memory, thereby making NULL have a "value" of 48? ;-) Just asking...
The value of a pointer and the value of the object to which
it points (if any), are distinct.
int i = 42; /* the value of 'i' is 42 */
int *p = &i; /* the value of 'p' is *NOT* 42 */
/* the value of 'p' is the memory address of 'i' */
The value of NULL is zero, or zero converted to type 'void*'.
The value of a pointer object after having NULL assigned to it is
"null pointer". This might or might not corresponding to a bit
pattern of all zeros, or the binary value of 48, or ... etc.
You didn't answer the question.
In your example, couldn't the value of 'p', which is the memory address
of 'i', be 48 if that is where 'i' resides (where the 42 is)?
--
Mabden This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Foobarius Frobinium |
last post by:
Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the...
|
by: Foobarius Frobinium |
last post by:
http://thelinuxlink.net/~fingolfin/pointer-guide/
I've made a lot of corrections, and put in more new stuff. I have
malloc and pointers to struct's and maybe a few more things and I'm
done.
...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| |
