Pointer comparison - NULL vs 0
Tom Ekberg
use 0 instead of NULL for pointer comparisions. He also claims that C++
people are moving to using 0 instead of NULL. I have read about 1500 headers
in comp.lang.c++ and comp.lang.c++.moderated as well as the Usenet C++ FAQ
and have come up empty (sorry for the minor pun :-) on this issue.
Stroustrup and the ANSI C++ language specification seem to indicate that
NULL is preferred, but state that 0 is also valid. I already know about the
danger of using 0 vs. NULL with overloaded functions. Anybody have an
opinion on this?
Tom Ekberg, TEk...@coyotetech.com
Coyote Technologies, LLC
972-889-5212
Andrew J Robb
type. C compilers sometimes defined NULL as ((void*)0) but this did
not work with function pointers. In C++ it is an
implementation-defined macro and only need be defined in the
compatibility headers:
<clocale>
<cstddef>
<cstdio>
<cstdlib>
<cstring>
<ctime>
<cwchar>
Of course it might also be defined in the old C headers.
OK so C programmers understand NULL but it does not have to be
available unless you use C features.
I tend to use 0.
Thomas
There is a recent discussion about NULL vs. 0 (zero) in the news:comp.lang.c
newsgroup.
The basic content of the discussion is that NULL and zero are equivalent. The
compiler can define NULL as anything, but it must convert it so that the
expression NULL == 0 is valid and true.
Whether to use NULL or zero is a religious issue. Everybody has their own
opinons; and it cannot be definitively resolved. Choose one and stick with it.
Truth is consistency.
--
Thomas Matthews
email: mat...@stamps.stortek.com
Bjarne Stroustrup
"Tom Ekberg" <tek...@coyotetech.com> writes:
> Someone at work is proposing a C++ coding style in which he wants people to
> use 0 instead of NULL for pointer comparisions. He also claims that C++
> people are moving to using 0 instead of NULL. I have read about 1500 headers
> in comp.lang.c++ and comp.lang.c++.moderated as well as the Usenet C++ FAQ
> and have come up empty (sorry for the minor pun :-) on this issue.
> Stroustrup and the ANSI C++ language specification seem to indicate that
> NULL is preferred, but state that 0 is also valid.
I use 0 and I don't recommend NULL. Here is a quote from "The C++ Programming
Language (3rd Edition)":
"In C, it has been popular to define a macro NULL to represent
the zero pointer. Because of C++''s tighter type checking, the
use of plain 0, rather than any suggested NULL macro, leads to
fewer problems."
> I already know about the
> danger of using 0 vs. NULL with overloaded functions. Anybody have an
> opinion on this?
Asking about 0 vs. NULL is a great way to start a flamewar :-(
- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs
Paul Lutus
fancy footwork behind the scenes to interpret "0" correctly in this context
(the NULL value is not guaranteed always to be zero in "reality").
Solely for readability purposes and comprehension, I recommend that pointers
be compared to NULL. To do otherwise may result is very strange bugs, like:
char *p = NULL;
assert(p == 0); // will succeed
// this next line assumes that sizeof(long) == sizeof(char *),
// not always true, but for this example:
long lp = (long)p;
assert(lp == 0); // not guaranteed to succeed
This recommendation is just my personal opinion, based on experience.
Paul Lutus
Tom Ekberg wrote in message <79n3mi$d...@journal.concentric.net>...
>Someone at work is proposing a C++ coding style in which he wants people to
<snip>
Biju Thomas
>
> I use 0 and I don't recommend NULL. Here is a quote from "The C++ Programming
> Language (3rd Edition)":
>
> "In C, it has been popular to define a macro NULL to represent
> the zero pointer. Because of C++''s tighter type checking, the
> use of plain 0, rather than any suggested NULL macro, leads to
> fewer problems."
I would greatly appreciate if anybody can explain why they recommend 0
and not NULL, given the folowing facts:
1. The C++ standard says that the NULL macro should be a null pointer
constant. It also says that '(void*)0' is not a proper definition of the
NULL macro.
2. Using NULL instead of 0 enhances readability of the code.
The only argument I can think of for using 0 instead of NULL is
compatibility with old compilers. Anything else?
--
Regards,
Biju Thomas
Paul Lutus
standard says that it is equivalent to 0. >>
My example shows that a pointer's value that equals NULL will also equal 0
only in a pointer context (but NULL and 0 will always equal one another if
directly compared). To say it more precisely, a pointer variable that is
equal to NULL or 0 in a pointer context may not equal 0 if the pointer's
value is divorced from its originating pointer context. As you point out, it
then will also not equal NULL.
My point is this this pointer-context use of 0 may lead to confusion with
the more common numerical interpretation of 0. In a pointer context, the
meaning of NULL is clearer than the meaning of 0, therefore (and IMHO) NULL
is preferred.
I find it regrettable that the term NULL was chosen for this use. It quite
literally means "zero" in German, as well as British informal prose, thus
adding to the confusion.
Just my personal opinion, as I said before.
Paul Lutus
Michael Rubenstein wrote in message
<36c08c88....@nntp.ix.netcom.com>...
>On Mon, 8 Feb 1999 14:01:28 -0800, "Paul Lutus" <nos...@nosite.com>
>wrote:
>
>>Using 0 instead of NULL will work, but only because the compiler does some
>>fancy footwork behind the scenes to interpret "0" correctly in this
context
>>(the NULL value is not guaranteed always to be zero in "reality").
>>
>>Solely for readability purposes and comprehension, I recommend that
pointers
>>be compared to NULL. To do otherwise may result is very strange bugs,
like:
>>
>>char *p = NULL;
>>
>>assert(p == 0); // will succeed
>>
>>// this next line assumes that sizeof(long) == sizeof(char *),
>>// not always true, but for this example:
>>
>>long lp = (long)p;
>>
>>assert(lp == 0); // not guaranteed to succeed
>>
>>This recommendation is just my personal opinion, based on experience.
>
>Note that in this case
>
> assert(lp == NULL);
>
>is also not guaranteed to succeed.
>
>Since NULL must be defined as an constant integer expression that
>evaluates to 0, using 0 for pointer comparisons is equivalent to using
>NULL.
>
>0 works because the standard says it must. NULL works because the
>standard says that it is equivalent to 0.
>--
>Michael M Rubenstein
Michael Rubenstein
Dave Harris
with characters, and using 0.0 (or 0.0f) when dealing with floating point,
and come up with a consistent policy across the board.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Michael Rubenstein
wrote:
><< 0 works because the standard says it must. NULL works because the
>standard says that it is equivalent to 0. >>
>
>My example shows that a pointer's value that equals NULL will also equal 0
>only in a pointer context (but NULL and 0 will always equal one another if
>directly compared). To say it more precisely, a pointer variable that is
>equal to NULL or 0 in a pointer context may not equal 0 if the pointer's
>value is divorced from its originating pointer context. As you point out, it
>then will also not equal NULL.
I guess it's time for me to drop out of this. It's obvious that my
psychic abilities are much too meager to carry on a discussion with
someone who says
the NULL value is not guaranteed always to be zero in
"reality"
when he really means that NULL is guaranteed always to zero but he
think NULL is clearer.
--
Michael M Rubenstein
jim.h...@leitch.com
AJR...@bigfoot.com (Andrew J Robb) wrote:
> I think that 0 is the only value that gets cast to a pointer of any
> type. C compilers sometimes defined NULL as ((void*)0) but this did
> not work with function pointers.
Note, BTW, that the C++ Standard explicitly states that "((void *)0)" is not
an acceptable definition of NULL.
Jim
Note to recruitment agencies: I will not refer my friends or colleagues
to you nor do I want to use your services to find me a job. I stop
reading unsolicited email as soon as I determine it is job-recruitment
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Jonathan H Lundquist
Bjarne <G>.
Biju Thomas <biju...@ibm.net> wrote in message
news:36BFB367...@ibm.net...
>Bjarne Stroustrup wrote:
>I would greatly appreciate if anybody can explain why they recommend 0
>and not NULL, given the folowing facts: ...
Tom Ekberg
> I use 0 and I don't recommend NULL. Here is a quote from "The C++
> Programming Language (3rd Edition)":
> "In C, it has been popular to define a macro NULL to represent
> the zero pointer. Because of C++''s tighter type checking, the
> use of plain 0, rather than any suggested NULL macro, leads to
> fewer problems."
I wrote:
> Stroustrup and the ANSI C++ language specification seem to indicate
> that NULL is preferred, but state that 0 is also valid.
I stand corrected. Obviously Bjarne Stroustrup can speak for himself better
than I can :-). Upon more careful and tedious examination of his book "The
C++ Programming Language (Second Edition)" (yes I scanned the entire book),
I noted eight conditional expressions of the form "if (p == 0)" and none of
the form "if (p == NULL)", where p is a pointer to some data.
My case for NULL goes has the following points:
(1) The Draft C++ standard
(http://www.cygnus.com/misc/wp/dec96pub/lib-support.html, I can't see paying
$265 to get the approved standard) states:
The macro NULL is an implementation-defined C++ null-pointer constant
in this International Standard (_conv.ptr_).1)
And in http://www.cygnus.com/misc/wp/dec96pub/conv.html:
An integral constant expression (_expr.const_) rvalue of integer type
that evaluates to zero (called a null pointer constant) can be con-
verted to a pointer type. The result is a value (called the null
pointer value of that type) distinguishable from every pointer to an
object or function. Two null pointer values of the same type shall
compare equal. The conversion of a null pointer constant to a pointer
to cv-qualified type is a single conversion, and not the sequence of a
pointer conversion followed by a qualification conversion
(_conv.qual_).
These together imply that NULL and 0 are both null pointer constants which
can be used in == or != comparisons with pointers.
(2) The use of NULL is wide-spread. This is an observation of the use of C++
since around 1985.
(3) 0 is a "magic" number and is greatly overloaded (there is probably a
better word than overloaded). It is better to use a named constant than to
use magic numbers.
(4) The of NULL in an equal coomparison shows that a pointer is being
compared.
The use of 0 must be interpreted by the reader by examining the type of the
other operand before the meaning can be determined.
(5) This issues is not discussed in the C++ FAQ. Perhaps it should.
Caius Marius
>when he really means that NULL is guaranteed always to zero but he
>think NULL is clearer.
The problem is that NULL is not guaranteed to be zero. There are compilers
that have NULL defined in such a way that it is incompatible with C++.
I agree that
if (x == NULL)
makes it clear that you are referencing a pointer. However, the trade off is
in portability.
John - N8086N
Wise man says "Never use a bank with the initials F. U."
------------------------------------ JPEG -----
Are you interested in a professional society or
guild for programmers?
See www.programmersguild.org/american.htm
EMail Address:
_m_i_a_n_o_@
_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s.
_c_o_m_
Paul Lutus
psychic abilities are much too meager to carry on a discussion with
someone who says
the NULL value is not guaranteed always to be zero in
"reality"
when he really means that NULL is guaranteed always to zero but he
think NULL is clearer. >>
I can't tell whether you are actually not understanding the point, or are
just being contrary for purposes of style.
Let me try again. On some platforms, the compiler will make sure that a
pointer that equals NULL also equals 0, but neither of these equalities
assures that the actual bit pattern in the pointer equals what a reasonable
person would recognize as "zero." This behavior is included in the language
specification -- it is meant to prevent programs from breaking on platforms
that, for one reason or another, do not allow NULL to equal the the actual
numerical value "zero".
For more on this subject, please read
http://www.eskimo.com/~scs/C-faq/q5.5.html.
Paul Lutus
Michael Rubenstein wrote in message
<36ca272d....@nntp.ix.netcom.com>...
<snip>
Paul Lutus
a way that is incompativle with C++ it is buggy. >>
And the C++ language standard allows NULL to assume any value it must, to
comply with the requirements of a particular architecture. This includes
requiring that NULL equal "0", and a NULL pointer equal "0", through some
compiler machinations, while at the same time not having a bit pattern equal
to numerical 0.
The issue is that the bit pattern represented by NULL is up to the compiler
and the implementation. It may not be equal to what we ordinarily would
think of as numerical "zero." Read about this at
http://www.eskimo.com/~scs/C-faq/q5.5.html.
Paul Lutus
Michael Rubenstein wrote in message
<36c2e5b0....@nntp.ix.netcom.com>...
<snip>
Paul Lutus
value zero. Its representation must be all zero bits. >>
Well, since you have no interest in finding out what the C++ standard says,
please stop posting on this issue. You are doing a disservice to the
students that read this newsgroup.
What can I say? You are as mistaken as you are sure of yourself.
Paul Lutus
Michael Rubenstein wrote in message
<36c50cd2....@nntp.ix.netcom.com>...
<snip>
Michael Rubenstein
wrote:
>Bjarne Stroustrup wrote:
>>
>> I use 0 and I don't recommend NULL. Here is a quote from "The C++ Programming
>> Language (3rd Edition)":
>>
>> "In C, it has been popular to define a macro NULL to represent
>> the zero pointer. Because of C++''s tighter type checking, the
>> use of plain 0, rather than any suggested NULL macro, leads to
>> fewer problems."
>
>I would greatly appreciate if anybody can explain why they recommend 0
>and not NULL, given the folowing facts:
>
>1. The C++ standard says that the NULL macro should be a null pointer
>constant. It also says that '(void*)0' is not a proper definition of the
>NULL macro.
>
>2. Using NULL instead of 0 enhances readability of the code.
>
>The only argument I can think of for using 0 instead of NULL is
>compatibility with old compilers. Anything else?
I prefer NULL as I agree that it enhances readability. However, it
also causes problems. My feeling is that it was a mistake to use 0
rather than a special identifier for the null pointer constant.
The main problem is that it is too easy misread NULL as implying a
pointer. That's the intent, but the compiler may not agree. Consider
void f(void*);
void f(int);
f(NULL);
which f will be called? Depending on how NULL is defined this is
either an error or f(int) will be called. In no case will f(void*) be
called.
--
Michael M Rubenstein
Michael Rubenstein
>In article <36ca272d....@nntp.ix.netcom.com>, mik...@ix.netcom.com (Michael Rubenstein) wrote:
>
>>when he really means that NULL is guaranteed always to zero but he
>>think NULL is clearer.
>
>The problem is that NULL is not guaranteed to be zero. There are compilers
>that have NULL defined in such a way that it is incompatible with C++.
Huh? We're talking about C++ here. If a C++ compiler defines NULL in
a way that is incompativle with C++ it is buggy. I have never said
that one should NULL is guaranteed to be 0 in other languages.
--
Michael M Rubenstein
Michael Rubenstein
wrote:
><< I guess it's time for me to drop out of this. It's obvious that my
>psychic abilities are much too meager to carry on a discussion with
>someone who says
>
>the NULL value is not guaranteed always to be zero in
>"reality"
>
>when he really means that NULL is guaranteed always to zero but he
>think NULL is clearer. >>
>
>I can't tell whether you are actually not understanding the point, or are
>just being contrary for purposes of style.
>
>Let me try again. On some platforms, the compiler will make sure that a
>pointer that equals NULL also equals 0, but neither of these equalities
>assures that the actual bit pattern in the pointer equals what a reasonable
>person would recognize as "zero." This behavior is included in the language
>specification -- it is meant to prevent programs from breaking on platforms
>that, for one reason or another, do not allow NULL to equal the the actual
>numerical value "zero".
Sigh. The standard requires that NULL equal the actual value 0. It
may be a different type, such as char or long, but it must equal 0.
The compiler makes sure that a pointer that equals NULL also equals 0
because NULL is always 0.
Since NULL is always 0, what the underlying bit pattern for a null
pointer is cannot affect the choice of NULL or 0.
True, the underlying bit pattern for a null pointer need not be all
bits 0, but that has nothing to do with the value of NULL.
I give up.
--
Michael M Rubenstein
Larry Brasfield
><< Huh? We're talking about C++ here. If a C++ compiler defines NULL in
>a way that is incompativle with C++ it is buggy. >>
>
>comply with the requirements of a particular architecture. This includes
>requiring that NULL equal "0", and a NULL pointer equal "0", through some
>compiler machinations, while at the same time not having a bit pattern equal
>to numerical 0.
>
>The issue is that the bit pattern represented by NULL is up to the compiler
>and the implementation. It may not be equal to what we ordinarily would
>think of as numerical "zero." Read about this at
>http://www.eskimo.com/~scs/C-faq/q5.5.html.
Since this is a C++ newgroup, it would be
more relevant to look at what the C++
standard has to say about this. It really
is too simple to be worth as many words
as this thread has engendered.
In ISO/ANSI C++, NULL is required to be
"an implementation-defined C++ null pointer
constant", and is introduced by an #include
of <cstddef>, <clocale>, <cstdio>, <cstdlib>,
<cstring> <ctime>, or <cwchar>.
Section 4.10 states "A null pointer constant
is an integral constant expression (5.19) rvalue
of integer type that evaluates to zero."
So all the stuff about what the implementation
might do with NULL, or equivalently, 0, is not
something to which the programmer is normally
exposed. A reinterpret_cast might expose it,
but that produces implentation defined results
anyway, as many C++ user know.
--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )
Michael Rubenstein
wrote:
><< Huh? We're talking about C++ here. If a C++ compiler defines NULL in
>a way that is incompativle with C++ it is buggy. >>
>
>And the C++ language standard allows NULL to assume any value it must, to
>comply with the requirements of a particular architecture. This includes
>requiring that NULL equal "0", and a NULL pointer equal "0", through some
>compiler machinations, while at the same time not having a bit pattern equal
>to numerical 0.
>
>The issue is that the bit pattern represented by NULL is up to the compiler
>and the implementation. It may not be equal to what we ordinarily would
>think of as numerical "zero." Read about this at
>http://www.eskimo.com/~scs/C-faq/q5.5.html.
The issue is that this is nonsense. NULL is an integer constant with
value zero. Its representation must be all zero bits.
The C++ standard allows NULL to assume any value it must, as long as
that value is zero and is represented by all zero bits.
A null pointer need not be represented by all zero bits, but since
NULL is not a null pointer (or any kind of pointer) that doesn't
matter. NULL is an integer and integers with value zero are
represented by all zero bits.
--
Michael M Rubenstein
Paul Black
>
> << The issue is that this is nonsense. NULL is an integer constant with
> value zero. Its representation must be all zero bits. >>
>
> please stop posting on this issue. You are doing a disservice to the
> students that read this newsgroup.
If you read section 4.10 of the standard, you would know he is correct.
Paul
Andrew J Robb
From reading ISO/IEC-14882:1998, it seems that NULL need only be
defined in the "compatibility" headers, <cstdio> etc.
It will also be defined in C headers - but this is a C++ group.
I don't want to use these headers. I assume that if I used NULL,
there is no guarantee that it will be defined.
Andrew J Robb
>value zero. Its representation must be all zero bits.
I think that the standard allows a null pointer to have bit
representations other than "all zero".
Was there a DEC machine where it was something else?
The standard is clear that assigning a pointer the value zero will
make it a null pointer. Also, comparing a null pointer to zero will
be true. It only defines bit-patterns for unsigned integral values.
There might be warnings in the C standard that calloc() should not be
trusted to generate null pointers (it just sets all bits to zero).
Michael Rubenstein
wrote:
><< The issue is that this is nonsense. NULL is an integer constant with
>value zero. Its representation must be all zero bits. >>
>
>Well, since you have no interest in finding out what the C++ standard says,
>please stop posting on this issue. You are doing a disservice to the
>students that read this newsgroup.
>
>What can I say? You are as mistaken as you are sure of yourself.
You could say that I know what the standard says and that the standard
requires NULL to be an integer with value 0. The standard does not
allow NULL to be any other value. What I am saying is based on the
standard. If you are going to lecture others about learning what is
in the standard, perhaps you should do so.
From 18.1,
The macro NULL is an implementation defined C++ null pointer
constant in this International Standard (4.10).
NULL must be some null pointer constant. What is a null pointer
constant? The definition of null pointer constant is in 4.10
A null pointer constant is an integral constant expression
(5.19) rvalue of integer type that evaluates to zero.
So, a null pointer constant is an integer with value 0.
There is a footnote in 18.1 explaining further:
Possible definitions [of NULL] include 0 and 0L, but not
(void*) 0.
--
Michael M Rubenstein
Michael Rubenstein
wrote:
>>The issue is that this is nonsense. NULL is an integer constant with
>>value zero. Its representation must be all zero bits.
>
>I think that the standard allows a null pointer to have bit
>representations other than "all zero".
>
>Was there a DEC machine where it was something else?
>
>The standard is clear that assigning a pointer the value zero will
>make it a null pointer. Also, comparing a null pointer to zero will
>be true. It only defines bit-patterns for unsigned integral values.
>
>There might be warnings in the C standard that calloc() should not be
>trusted to generate null pointers (it just sets all bits to zero).
There's no question that the standard allows a null pointer to have a
bit representation other than all zero. In fact, if you had quoted
the next paragraph of my article you would have found that I said
that:
A null pointer need not be represented by all zero bits...
But this has nothing to do with NULL. The standard does not allow
NULL to be a null pointer; NULL is an integer with value zero which
must be represented by all zero bits.
--
Michael M Rubenstein
jim.h...@leitch.com
mik...@ix.netcom.com (Michael Rubenstein) wrote:
> On Tue, 9 Feb 1999 19:41:33 -0800, "Paul Lutus" <nos...@nosite.com>
> wrote:
>
> ><< Huh? We're talking about C++ here. If a C++ compiler defines NULL in
> >a way that is incompativle with C++ it is buggy. >>
> >
> >And the C++ language standard allows NULL to assume any value it must, to
> >comply with the requirements of a particular architecture. This includes
> >requiring that NULL equal "0", and a NULL pointer equal "0", through some
> >compiler machinations, while at the same time not having a bit pattern equal
> >to numerical 0.
> >
> >The issue is that the bit pattern represented by NULL is up to the compiler
> >and the implementation. It may not be equal to what we ordinarily would
> >think of as numerical "zero." Read about this at
> >http://www.eskimo.com/~scs/C-faq/q5.5.html.
>
> value zero. Its representation must be all zero bits.
>
Wait a second! NULL's physical representation is independent of what you
write. You may write:
void *p=0; // or =NULL;
but if your compiler is targeting a system where an invalid pointer is
represented (by the CPU design) by the value, oh, 0xABABABAB, then the
compiler will write assembly code that puts the value 0xABABABAB into the
address space of p. If you then write a few more lines, and then:
assert(p != 0)
the compiler will generate machine code that will compare the contents of p
with 0xABABABAB, not 0.
> A null pointer need not be represented by all zero bits, but since
> NULL is not a null pointer (or any kind of pointer) that doesn't
> matter. NULL is an integer and integers with value zero are
> represented by all zero bits.
Oh, wait, I think I see what you're getting at - say the compiler defines NULL
as:
#define NULL 0
and in your code you write:
void *p=NULL;
int i=NULL;
the bit representation of i would be all zero bits, but the bit representation
of p would be (on the same hypothetical machine mentioned above) 0xABABABAB.
Paul Lutus
would have been a better way to put it than the one I chose.
A hypothetical conversation between a student and an experienced programmer:
S: NULL equals 0, right?
E: Yes.
S: I can assign the value NULL to a pointer, right?
E Yes.
S: And if I assign 0 to that pointer, it's the same outcome, right?
E: Yes.
S: If I then compare that pointer to either NULL or 0, equivalence will be
indicated in both cases, right?
E: Yes.
S: Does that mean if I examine the value contained in the pointer using a
debugger in a compiled program, it will equal zero?
E: Not necessarily. This depends on the platform.
You see, arguing (as you have) how NULL is defined by the standard is a side
issue, if the compiler can, in some cases, use the presence of NULL or 0 in
a pointer context to do something counterintuitive. And that
counterintuitive behavior is specified in (or permitted by) the standard,
and is in fact embodied in some compilers on some platforms.
Maybe we should stop this now. Most of our posts are more confusing than
enlightening anyway.
Paul Lutus
Michael Rubenstein wrote in message
<36c67738....@nntp.ix.netcom.com>...
<snip>
Paul Lutus
>>
I shouldn't have used the word "Wrong." I should have said "Misleading."
(a copy of part of my reply to Michael --)
A hypothetical conversation between a student and an experienced programmer:
S: NULL equals 0, right?
E: Yes.
S: I can assign the value NULL to a pointer, right?
E Yes.
S: And if I assign 0 to that pointer, it's the same outcome, right?
E: Yes.
S: If I then compare that pointer to either NULL or 0, equivalence will be
indicated in both cases, right?
E: Yes.
S: Does that mean if I examine the value contained in the pointer using a
debugger in a compiled program, it will equal zero?
E: Not necessarily. This depends on the platform.
Arguing how NULL is defined by the standard is a side issue, if the compiler
can, in some cases, use the presence of NULL or 0 in a pointer context to do
something counterintuitive. And that counterintuitive behavior is specified
in (or permitted by) the standard, and is in fact embodied in some compilers
on some platforms.
Paul Lutus
Paul Black wrote in message <36C14DB8...@tcam.com>...
>"Paul Lutus" <nos...@nosite.com> wrote:
>>
>> << The issue is that this is nonsense. NULL is an integer constant with
>> value zero. Its representation must be all zero bits. >>
>>
>> Well, since you have no interest in finding out what the C++ standard
says,
>> please stop posting on this issue. You are doing a disservice to the
>> students that read this newsgroup.
>
Michael Rubenstein
wrote:
>I could (nay, should) have said, "You are clouding the original issue." That
>would have been a better way to put it than the one I chose.
>
>A hypothetical conversation between a student and an experienced programmer:
>
>S: NULL equals 0, right?
>E: Yes.
>S: I can assign the value NULL to a pointer, right?
>E Yes.
>S: And if I assign 0 to that pointer, it's the same outcome, right?
>E: Yes.
>S: If I then compare that pointer to either NULL or 0, equivalence will be
>indicated in both cases, right?
>E: Yes.
>S: Does that mean if I examine the value contained in the pointer using a
>debugger in a compiled program, it will equal zero?
>E: Not necessarily. This depends on the platform.
>
>You see, arguing (as you have) how NULL is defined by the standard is a side
>issue, if the compiler can, in some cases, use the presence of NULL or 0 in
>a pointer context to do something counterintuitive. And that
>counterintuitive behavior is specified in (or permitted by) the standard,
>and is in fact embodied in some compilers on some platforms.
Please be careful. Whiplash could cause serious injury to your back
when you change directions that quickly.
When I say that the representation of a null pointer need not be all
zero bits, but that NULL must be zero, you write
Well, since you have no interest in finding out what the C++
standard says, please stop posting on this issue. You are
doing a disservice to the students that read this newsgroup.
What can I say? You are as mistaken as you are sure of
yourself.
Now, when I point out that what I am saying is from the standard you
say that arguing about what the standard says is a side issue.
Twit.
--
Michael M Rubenstein
Paul Lutus
Nice going, sir. I especially like how well you manage to avoid personal
attacks while engaged in a "technical" discussion.
My assertion throughout this thread: pointers that are assigned the value
NULL are not necessarily equal to the everyday value "zero."
Your assertion: NULL is always equal to zero.
This is a matter not under discussion. I mistakenly believed you were
addressing the subject of the thread -- the actual content of a pointer to
which NULL had been assigned, which should be obvious from my posts. And I
went on with this mistaken assumption practically forever.
Your way of posting to this thread indicates that you love arguments and are
not particularly fond of clarity. And when it comes time for an ad hominem
(as exemplified above), well -- heaven.
Your way of expressing your correct (and tautological) view is (1)
irrelevant to the subject of the thread, and (2) misleading. A complying
compiler, when confronted with a pointer assignment to, or comparison with,
NULL or 0, is free to disregard that defined value and replace it with
something else in both cases. That is the matter I have been trying to
explain, for example:
<< My example shows that a pointer's value that equals NULL will also equal
0
only in a pointer context >>
I clearly am speaking of the content of a pointer to which NULL has been
assigned, not the defined value of NULL. You took this in a different
direction, arguing that NULL (not a pointer to which NULL has been assigned)
is actually equal to 0. And I managed not to notice that the subject had
changed.
Now for the second time -- let's drop this.
Paul Lutus
Michael Rubenstein wrote in message
<36cb13f2....@nntp.ix.netcom.com>...
<snip>
Michael Rubenstein
>In article <36c50cd2....@nntp.ix.netcom.com>,
> mik...@ix.netcom.com (Michael Rubenstein) wrote:
>> The C++ standard allows NULL to assume any value it must, as long as
>> that value is zero and is represented by all zero bits.
>
>Wait a second! NULL's physical representation is independent of what you
>write.
Isn't that what I said?
And what color Model T would you like? :-)
--
Michael M Rubenstein
Andrew Koenig
> My assertion throughout this thread: pointers that are assigned the value
> NULL are not necessarily equal to the everyday value "zero."
But they are!. That is, for all types T,
T* p = NULL;
if (p == 0)
cout << "equal" << endl;
else
cout << "not equal" << endl;
will print "equal".
Now, I completely agree that the internal representation of p might not
consist entirely of zero bits, so whether your assertion is correct or not
hinges on the interpretation of ``equal to the everyday value "zero"''.
I suspect that a lot of people will assume that the expression "p == 0"
is what one would use to determine whether p is equal to the everyday
value "zero". From the context, that's clearly not what you meant,
so perhaps you should pick a phrase with less capacity for ambiguous
interpretation.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Paul Lutus
should pick a phrase with less capacity for ambiguous interpretation. >>
I completely agree. I will pick one of my own from this thread (and edit one
line for clarity):
(S =- student, E= experienced programmer)
S: NULL equals 0, right?
E: Yes.
S: I can assign the value NULL to a pointer, right?
E Yes.
S: And if I assign 0 to that pointer, it's the same outcome, right?
E: Yes.
S: If I then compare that pointer to either NULL or 0, equivalence will be
indicated in both cases, right?
E: Yes.
S: Does that mean if I examine the value contained in the pointer using a
debugger in a compiled program, it will equal zero?
E: Not necessarily. Because of hardware constraints, some platforms must use
a "NULL-pointer" value other than 0. In cases like this, the compiler is
free to replace all pointer-context references to "0" or "NULL" in the
source listing with a locally defined value. This platform-defined value can
be seen by examining the executable's machine-specific code in a
disassembler or debugger.
Please feel free to add to my explanation -- this is, after all, a rather
bizarre case of the relationship between a formal language definition and
the actual outcome in a running program (as this thread amply demonstrates).
Paul Lutus
Andrew Koenig wrote in message ...
<snip>
Michael Rubenstein
wrote:
><< From the context, that's clearly not what you meant, so perhaps you
And, of course, leaving out the ridiculous statment you kept making
that NULL need not be 0.
No one has claimed that nothing you wrote was correct. If you look at
my posts, you will find that what I objected to was statements like
the NULL value is not guaranteed always to be zero in
"reality"
and
And the C++ language standard allows NULL to assume any value
it must, to comply with the requirements of a particular
architecture.
Of course, it's always easier to use nonstandard terminology, berate
someone for not knowing or caring about the standard, and then saying
the standard is not relevent when he points out that he is correct.
NULL has a meaning defined by the standard. It is reasonable in this
newsgroup to assume that someone who uses the term NULL intends that
meaning.
--
Michael M Rubenstein
Andrew Koenig
> (S =- student, E= experienced programmer)
> S: NULL equals 0, right?
> E: Yes.
> S: I can assign the value NULL to a pointer, right?
> E Yes.
> S: And if I assign 0 to that pointer, it's the same outcome, right?
> E: Yes.
> S: If I then compare that pointer to either NULL or 0, equivalence will be
> indicated in both cases, right?
> E: Yes.
> S: Does that mean if I examine the value contained in the pointer using a
> debugger in a compiled program, it will equal zero?
> E: Not necessarily. Because of hardware constraints, some platforms must use
> a "NULL-pointer" value other than 0. In cases like this, the compiler is
> free to replace all pointer-context references to "0" or "NULL" in the
> source listing with a locally defined value. This platform-defined value can
> be seen by examining the executable's machine-specific code in a
> disassembler or debugger.
> Please feel free to add to my explanation -- this is, after all, a rather
> bizarre case of the relationship between a formal language definition and
> the actual outcome in a running program (as this thread amply demonstrates).
Invitation accepted:
S: 0.0 equals 0, right?
E: Yes.
S: I can assign the value 0 to a floating-point variable, right?
E: Yes.
S: And if I assign 0.0 to that floating-point variable, it's the same outcome, right?
E: Yes.
S: If I then compare that floating-point variable to either 0.0 or 0,
equivalence will be indicated in both cases, right?
E: Yes.
S: Does that mean if I examine the value contained in the floating-point variable
using a debugger in a compiled program, it will equal zero?
E: Not necessarily. Because of hardware constraints, some platforms must
represent floating-point values in such a way that a value of zero
does not have all bits equal to zero. In cases like this, the compiler
is free to replace all floating-point-context references to 0 or 0.0
with an appropriate representation. This platform-defined value can
be seen by examing the executable's machine-specific code in a
disassembler or debugger.
Now as it happens, most machines represent floating-point zero as a value
with all bits zero, because the IEEE floating-point standard requires it,
and the IBM mainframe floating-point format does so as well. Similarly,
most machines represent null pointers as a value with all bits zero,
because such a representation fits well with their particular architecture.
But in both cases, it is easy to imagine machines in which that particular
representational equivalence does not apply.
Michael Rubenstein
wrote:
><< Twit. >>
>
>Nice going, sir. I especially like how well you manage to avoid personal
>attacks while engaged in a "technical" discussion.
>
>My assertion throughout this thread: pointers that are assigned the value
>NULL are not necessarily equal to the everyday value "zero."
>
>Your assertion: NULL is always equal to zero.
>
>This is a matter not under discussion. I mistakenly believed you were
>addressing the subject of the thread -- the actual content of a pointer to
>which NULL had been assigned, which should be obvious from my posts. And I
>went on with this mistaken assumption practically forever.
>
>Your way of posting to this thread indicates that you love arguments and are
>not particularly fond of clarity. And when it comes time for an ad hominem
>(as exemplified above), well -- heaven.
Nice going sir. You accuse me of not knowing or caring about the
standard and then when I point out that I am right about what the
standard says, you say it is irrelevant. In other words, it would be
bad if I didn't care about the standard, but you don't care about it.
When I respond in kind, you beat your breast about my personal attack.
I do apologize for the comment. I should not have stooped to your
level.
>
>Your way of expressing your correct (and tautological) view is (1)
>irrelevant to the subject of the thread, and (2) misleading. A complying
>compiler, when confronted with a pointer assignment to, or comparison with,
>NULL or 0, is free to disregard that defined value and replace it with
>something else in both cases. That is the matter I have been trying to
>explain, for example:
>
><< My example shows that a pointer's value that equals NULL will also equal
>0
>only in a pointer context >>
>
>I clearly am speaking of the content of a pointer to which NULL has been
>assigned, not the defined value of NULL. You took this in a different
>direction, arguing that NULL (not a pointer to which NULL has been assigned)
>is actually equal to 0. And I managed not to notice that the subject had
>changed.
You said that NULL is not necessarily zero. NULL is defined by the
standard and I, obviously foolishly, assumed that you were using the
standard meaning. In several of my posts I said that a null pointer
was not necessarily all zero bits. You then repeated your statement
that NULL is not necessarily zero.
>
>Now for the second time -- let's drop this.
You can drop it too. I promise that when you stop posting nonsense I
will stop pointing out that it is nonsense.
--
Michael M Rubenstein
Richardson, Robert D
does the standard say about NULL?
Rob
Michael Rubenstein
From 18.1:
The macro NULL is an implementationè‹“efined C++ null pointer
constant in this International Standard (4.10).
The term null pointer constant is defined in 4.10:
A null pointer constant is an integral constant expression
(5.19) rvalue of integer type that evaluates to zero.
Note that this definition is different from that in the C standard. C
also allows a null pointer constant to be such an expression cast to
void*.
Why is this important? Why do I object to Paul's statement that NULL
need not be 0? It's simple. Note that a null pointer constant, and
therefore NULL, is not a pointer. It is an integer (not necessarily
an int) with value zero.
Thinking of NULL as a pointer can lead to some nasty bugs. Consider
void f(int);
void f(void*);
f(NULL);
Depending on how NULL is defined this will either call f(int) with an
argument of 0 (e.g., if NULL is '\0' or int) or result in a diagnostic
(e.g., if NULL is 0L). In no case will it call f(void*). It is very
important that a C++ programmer understand that NULL is an integer
with value 0.
Bjarne Stroustrup and others advocate using 0 rather than NULL.
Others, including myself, do not agree and have preferred NULL as
being clearer in the code. While I'm not ready to agree with
Stroustrup yet, this thread is causing me to rethink my views. As
Paul's posts demonstrate, it's awfully easy to fall into the trap of
thinking of NULL as a pointer.
I think it unfortunate that C++ does not have a "true" null pointer
constant (i.e., one that is actually a pointer), but that's the way it
is. This may never change and will certainly not change soon.
--
Michael M Rubenstein
Michel Pitermann
> Sigh. The standard requires that NULL equal the actual value 0. It
> .
> .
> .
> I give up.
Your explanations were very clear. I did not know that NULL could not be a
pointer, and I understand better why people prefer to use 0.
On another level, I am wondering why some people care about bit representations
of types, like pointers in this thread. Some argue that using a debuger could
be misleading. But according to me, a good debuger should interpret any
expression. Instead of printing raw memory, I always check a variable content
interpreted by my debuger. For example, to know what is the content of pointer
"p", I never read memory in "&p", but do a "print p". As Andrew Koening
pointed out, it is not mandatory that the floating number 0.0 is represented by
all bits set to 0. But who cares?
Best regards,
pit
--
Michel Pitermann, Department of Psychology, Queen's University,
Kingston, Ontario, Canada K7L 3N6. mpi...@psyc.queensu.ca
Tel: +1 - 613 - 533 6000 ext 75754 Fax: +1 - 613 - 533 2499
Paul Lutus
newsgroup to assume that someone who uses the term NULL intends that
meaning. >>
I would say there are two meanings, which is what got me into trouble with
you in the first place -- I believed you were talking about the compiler's
treatment of NULL and 0 on some platforms, when in fact you were talking
about the standard's definition of the initial value that NULL assumes,
before the compiler exercises any latitude over this value, on some
platforms.
Therefore IMHO the assumption that there is only one reasonable
interpretation for NULL isn't really safe. It is, after all, a short hop
from saying "Doesn't the compiler have some latitude in how it handles
"NULL" and "0" references in a pointer context?" to saying "Isn't it
simplistic to assert that NULL always equals zero?"
If we are talking about the content of the standard, or one's expectations
about the majority of compiler behaviors, the answer to the second question
is the one you gave (I am paraphrasing) -- "Not at all. NULL is defined by
the standard as having the value 0, period."
If we are talking about the value assigned by a compiler in a
pointer-context NULL (or 0) assignment (or comparison) as a program is
compiled, then things get more complex.
I apologize for my overly terse, sloppy prose throughout this thread. On
re-reading it, I see at the beginning I used far too few words for the
innate complexity of the subject. In general, I think too many words are
used to describe most technical subjects -- I think this subject is an
exception to that rule.
Paul Lutus
Michael Rubenstein wrote in message
<36c71ac1....@nntp.ix.netcom.com>...
<snip>
Paul Lutus
sense and first impressions fail us. Where the number of real-world
possibilities are not obvious at first glance.
Paul Lutus
Andrew Koenig wrote in message ...
>Invitation accepted:
>
>S: 0.0 equals 0, right?
>E: Yes.
>S: I can assign the value 0 to a floating-point variable, right?
<snip>
Paul Lutus
that it is nonsense >>
On a separate, distantly related subject: do you really this this is
productive communication? It must be obvious to you that we both held to our
positions, and both our positions had some degree of merit. It is as easy
for me to say that NULL isn't really equal 0 in all cases (after being
assigned to a pointer, for example, after which that pointer is assumed to
contain the NULL value, and in fact can successfully be compared to NULL) as
it is for you to say NULL always equals 0, period (my paraphrase). The truth
is neither of these positions tells the whole story. And purely
argumentative statements only generate heat, no light.
So go ahead and argue if you will, but please avoid the pure variety, which
this represents.
Paul Lutus
Michael Rubenstein wrote in message
<36c820d9....@nntp.ix.netcom.com>...
<snip>
Paul Lutus
Programmers, who sometimes have to try to figure out what is going on in a
misbehaving program? My favorite example in regard to the subject of this
thread:
char *p = NULL;
assert(p == 0); // absolutely and always!
long lp = (long)p; // divorced from a pointer context
assert(lp == 0); // not necessarily...
My example makes the simplifying, sometimes incorrect assumption that
sizeof(long) == sizeof (char *).
Paul Lutus
Michel Pitermann wrote in message <1h1zjwv...@vip.psyc.Queensu.Ca>...
<snip>
Paul Lutus
several times that a null pointer need not be represented by all zero
bits. >>
I did so with regard to a purely argumentative remark you made, and I
supplied the text, lest there be any confusion. This method did not work --
you deleted the quoted remark in your reply, and didn't thereafter refer to
it in any way.
Are we done now? This thread is getting tiresome. I am not as interested in
this style of argument (or its duration) as you obviously are. I think we
both have stated our views quite clearly.
Paul Lutus
Michael Rubenstein wrote in message
<36d07367....@nntp.ix.netcom.com>...
<snip>
Matt Austern
> Are we done now? This thread is getting tiresome. I am not as interested in
> this style of argument (or its duration) as you obviously are. I think we
> both have stated our views quite clearly.
"After one of the regular flame wars on comp.lang.c++ and comp.lang.c,
one of my friends observed, `If 0 is their worst problem, then they
are truly lucky.'"
-- Bjarne Stroustrup, in The Design and Evolution of C++
Paul Lutus
one of my friends observed, `If 0 is their worst problem, then they
are truly lucky.'"
-- Bjarne Stroustrup, in The Design and Evolution of C++
With regard to the present exchange, this was more of an ember war. Probably
why it lasted so long :)
Paul Lutus
Matt Austern wrote in message ...
<snip>
Seth Jones
says...
> On Thu, 11 Feb 1999 13:34:12 -0500, "Richardson, Robert D"
> <Robert.R...@bailey.com> wrote:
>
> >So that I can follow this thread a little more closely, what exactly
> >does the standard say about NULL?
>
> From 18.1:
>
> The macro NULL is an implementationè‹“efined C++ null pointer
> constant in this International Standard (4.10).
>
> The term null pointer constant is defined in 4.10:
>
> A null pointer constant is an integral constant expression
> (5.19) rvalue of integer type that evaluates to zero.
>
> Note that this definition is different from that in the C standard. C
> also allows a null pointer constant to be such an expression cast to
> void*.
Based on that, I have a suspicion that the standards committee was not
being careful with their terminology. If they had intended that NULL was
always defined as 0, they should (and probably would) have simply said
that. The qualifier "implementation-defined" strongly suggests that they
intended to allow NULL to have other values (although I have no idea why
that might be desirable).
Seth Jones
Michael Rubenstein
wrote:
>On a separate, distantly related subject: do you really this this is
>productive communication? It must be obvious to you that we both held to our
>positions, and both our positions had some degree of merit. It is as easy
>for me to say that NULL isn't really equal 0 in all cases (after being
>assigned to a pointer, for example, after which that pointer is assumed to
>contain the NULL value, and in fact can successfully be compared to NULL) as
>it is for you to say NULL always equals 0, period (my paraphrase). The truth
>is neither of these positions tells the whole story. And purely
>argumentative statements only generate heat, no light.
>
>So go ahead and argue if you will, but please avoid the pure variety, which
>this represents.
You accuse me of being purely argumentative, but I have clearly said
several times that a null pointer need not be represented by all zero
bits. In other words, a null (or, if you prefer, a zero) pointer need
not be represented in the same way as a zero integer. As Andrew
Koenig has pointed out, this is hardly unique to pointers.
Perhaps you were confused because I used the term that appears in the
standard with this meaning, null pointer, rather than inventing a new
meaning for NULL.
Yes, I believe it is productive. There are beginners who may learn
1. NULL is defined by the standard as an integer. It is
converted to a null pointer when it is assigned or
compared to a pointer.
2. This is important. The standard matters. When one uses a
term defined in the standard, it is reasonable to expect
one means that term. It is important to understand that
NULL is an integer.
Don't make the mistake of believing that I had any illusions that you
would learn this. I am not at all disappointed at the results of this
discussion.
--
Michael M Rubenstein
Michael Rubenstein
No. They intended to allow NULL to have other types. I believe that
this is very carefully worded and that the standards committee
intended exactly what it says.
Normally when the standard says something is implementation-defined it
imposes some restrictions on how it may be defined. Here the standard
requires that it be a null pointer constant. 4.10 allows a lot of
different things to be null pointer constants, but all of them have
value zero, and 18.1 allows NULL to be defined as any of them.
For example, NULL might be defined as 0, but it might also be defined
as 0L. Some consider the latter an advantage when a long is the same
size as a pointer to object and int is not.
While it's harder to come up with good reasons for doing so (read: I
can't), the standard allows other definitions such as
#define NULL '0'
#define NULL (73 - 73)
or
#define NULL (1 / 2)
--
Michael M Rubenstein
the Swamp Wizard
sometimes as 0xcdcdcdcd
In article <79s5lp$huu$1...@nnrp1.dejanews.com>, jim.h...@leitch.com says...
>
>In article <36c50cd2....@nntp.ix.netcom.com>,
> mik...@ix.netcom.com (Michael Rubenstein) wrote:
>> On Tue, 9 Feb 1999 19:41:33 -0800, "Paul Lutus" <nos...@nosite.com>
>> wrote:
>>
>> ><< Huh? We're talking about C++ here. If a C++ compiler defines NULL in
>> >a way that is incompativle with C++ it is buggy. >>
>> >
>> >And the C++ language standard allows NULL to assume any value it must, to
>> >comply with the requirements of a particular architecture. This includes
>> >requiring that NULL equal "0", and a NULL pointer equal "0", through some
>> >compiler machinations, while at the same time not having a bit pattern
equal
>> >to numerical 0.
>> >
>> >The issue is that the bit pattern represented by NULL is up to the compiler
>> >and the implementation. It may not be equal to what we ordinarily would
>> >think of as numerical "zero." Read about this at
>> >http://www.eskimo.com/~scs/C-faq/q5.5.html.
>>
>> The issue is that this is nonsense. NULL is an integer constant with
>> value zero. Its representation must be all zero bits.
>>
>> The C++ standard allows NULL to assume any value it must, as long as
>> that value is zero and is represented by all zero bits.
>
>Wait a second! NULL's physical representation is independent of what you
>write. You may write:
>
>void *p=0; // or =NULL;
>
>but if your compiler is targeting a system where an invalid pointer is
>represented (by the CPU design) by the value, oh, 0xABABABAB, then the
>compiler will write assembly code that puts the value 0xABABABAB into the
>address space of p. If you then write a few more lines, and then:
>
>assert(p != 0)
>
>the compiler will generate machine code that will compare the contents of p
>with 0xABABABAB, not 0.
>
>> A null pointer need not be represented by all zero bits, but since
>> NULL is not a null pointer (or any kind of pointer) that doesn't
>> matter. NULL is an integer and integers with value zero are
>> represented by all zero bits.
>Oh, wait, I think I see what you're getting at - say the compiler defines NULL
>as:
>
>#define NULL 0
>
>and in your code you write:
>
>void *p=NULL;
>int i=NULL;
>
>the bit representation of i would be all zero bits, but the bit representation
>of p would be (on the same hypothetical machine mentioned above) 0xABABABAB.
>
>Jim
>Note to recruitment agencies: I will not refer my friends or colleagues
>to you nor do I want to use your services to find me a job. I stop
>reading unsolicited email as soon as I determine it is job-recruitment
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Jan Christiaan van Winkel
: Now as it happens, most machines represent floating-point zero as a value
: with all bits zero, because the IEEE floating-point standard requires it,
: and the IBM mainframe floating-point format does so as well. Similarly,
: most machines represent null pointers as a value with all bits zero,
: because such a representation fits well with their particular architecture.
: But in both cases, it is easy to imagine machines in which that particular
: representational equivalence does not apply.
As a matter of fact, the Microsoft Basic floating point format (used in the
seventies and eighties on 8080 CP/M and 8086 MS-DOS 1.0), used one
single bit in the floating point representation to mark that the value
really was 0.0. Set the bit to one, and all ather bits are irrelevant.
Leter the IEEE format took over the world, but until that time, I have
done some bit-fiddling with the zero-indicator in float numbers...
As far as 0-pointers are concerned, I believe Pr1me machines (with a
segmented memory archetecture) used a special segment for null pointers.
Pointers were sort of pairs with a segment number and a offset. For
0-pointers, the segment had a very specific non-zero value that
triggered the hardware to generate an interrupt whenever an address with
that segment number was dereferenced.
So yes, non-null machine implementations of the 0-pointer do (did?)
excist.
JC
--
___ __ ____________________________________________________________________
|/ \ Jan Christiaan van Winkel Tel: +31 24 3527252 j...@ATComputing.nl
| AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands
__/ \__/ __________ http://www.ATcomputing.nl/images/pasfotos/jc.jpg ________
mfu...@my-dejanews.com
"Paul Lutus" <nos...@nosite.com> wrote:
> << I promise that when you stop posting nonsense I will stop pointing out
> that it is nonsense >>
>
> productive communication? It must be obvious to you that we both held to our
> positions, and both our positions had some degree of merit. It is as easy
> for me to say that NULL isn't really equal 0 in all cases (after being
> assigned to a pointer, for example, after which that pointer is assumed to
> contain the NULL value, and in fact can successfully be compared to NULL) as
> it is for you to say NULL always equals 0, period (my paraphrase). The truth
> is neither of these positions tells the whole story. And purely
> argumentative statements only generate heat, no light.
May be you correct that neither of these positions tells the whole story, but
your position is plain wrong! "NULL", as it defined by standard, is always
equal 0 - actually we can say that it is 0. As about pointer that contains
"null-value" - it is also equal to 0 in all cases (that means that if "p" is
a pointer after either "p = NULL;" or "p = 0;" expression "p == 0" will
evaluate to "true").
And it does not depend on the bit pattern that is used by hardware to
represent such null-pointer.
> [...]
mfu...@my-dejanews.com
mik...@ix.netcom.com (Michael Rubenstein) wrote:
> [...]
>
> While it's harder to come up with good reasons for doing so (read: I
> can't), the standard allows other definitions such as
>
> #define NULL '0'
Did you mean
#define NULL '\0'
?????
Paul Lutus
all cases >>
The compiler will make sure this appears to be true on all platforms, but a
debugger, examining a compiled program, may in some cases reveal something
else, something that is permitted by the standard. And it is possible to
test for this behavior in source code, without relying on a debugger (some
may regard that as "cheating"):
char *p = NULL;
assert(p == 0); // absolutely and always!
long lp = (long)p; // divorced from a pointer context
assert(lp == 0); // not necessarily...
My example makes the simplifying, sometimes incorrect assumption that
sizeof(long) == sizeof (char *).
Yours is the kind of position that, although correct on the surface, is
misleading if closely examined, and was in fact the genesis of this (overly
long) thread. Please take the time to read (1) this entire thread, and (2)
http://www.eskimo.com/~scs/C-faq/q5.5.html.
Paul Lutus
mfu...@my-dejanews.com wrote in message
<7a1ne8$f5i$1...@nnrp1.dejanews.com>...
<snip>
Paul Lutus
sometimes as 0xcdcdcdcd >>
This is actually a separate issue, one much easier to explain. If you do not
assign a value to a pointer, and depending on the (1) compiler, (2)
platform, and (3) chosen compilation mode, you may see any random value for
that pointer.
If, by contrast, you assign NULL to each pointer that has been assigned no
specific value, the effect you describe will go away (unless you examine
those pointers with a debugger on some platforms).
Paul Lutus
the Swamp Wizard wrote in message <7a0mgj$gv1$1...@nntp.gulfsouth.verio.net>...
Michael Rubenstein
>In article <36d48299....@nntp.ix.netcom.com>,
> mik...@ix.netcom.com (Michael Rubenstein) wrote:
>> [...]
>>
>> While it's harder to come up with good reasons for doing so (read: I
>> can't), the standard allows other definitions such as
>>
>> #define NULL '0'
>
>Did you mean
>
> #define NULL '\0'
Whoops. Yes. '0', of course, does not have the value 0.
--
Michael M Rubenstein
Michel Pitermann
> Programmers, who sometimes have to try to figure out what is going on in a
> misbehaving program? My favorite example in regard to the subject of this
> thread:
>
> char *p = NULL;
>
> assert(p == 0); // absolutely and always!
>
> long lp = (long)p; // divorced from a pointer context
>
> assert(lp == 0); // not necessarily...
Thanks to this thread and mostly to Michael's explanation, my understanding of
this example is that NULL is an integer (not necessarily int) set to 0. Then
your first instruction "char *p = NULL;" promotes this integer to a "null
pointer" which may not have all bits set to 0. Then "long lp = (long)p;"
promote the "null pointer" to a long integer value. Does not the standard
impose that promotion of "null pointer" to integer is 0? After all, the
standard garanties that integral-0 promotion to floating-point type, then
inverse promotion will lead to 0, irrespectively to the underlying bit
representation of those types!
Paul Lutus
is 0? After all, the standard garanties that integral-0 promotion to
floating-point type, then inverse promotion will lead to 0, irrespectively
to the underlying bit representation of those types! >>
This is a good question, and I don't know the answer. I have always assumed
that one could acquire the actual value in a pointer by casting it like
this. But it is no more than an assumption, and I have never owned a machine
in which the "special conditions" apply (nonzero bit pattern for pointer
containing NULL).
Paul Lutus
Michel Pitermann wrote in message <1hogmzf...@vip.psyc.Queensu.Ca>...
Michael Rubenstein
<mpi...@vip.psyc.Queensu.Ca> wrote:
>"Paul Lutus" <nos...@nosite.com> writes:
>
>> Programmers, who sometimes have to try to figure out what is going on in a
>> misbehaving program? My favorite example in regard to the subject of this
>> thread:
>>
>> char *p = NULL;
>>
>> assert(p == 0); // absolutely and always!
>>
>> long lp = (long)p; // divorced from a pointer context
>>
>> assert(lp == 0); // not necessarily...
>
>Thanks to this thread and mostly to Michael's explanation, my understanding of
>this example is that NULL is an integer (not necessarily int) set to 0. Then
>your first instruction "char *p = NULL;" promotes this integer to a "null
>pointer" which may not have all bits set to 0. Then "long lp = (long)p;"
>promote the "null pointer" to a long integer value. Does not the standard
>impose that promotion of "null pointer" to integer is 0? After all, the
>standard garanties that integral-0 promotion to floating-point type, then
>inverse promotion will lead to 0, irrespectively to the underlying bit
>representation of those types!
No. First, it's important to note that the standard only requires
that a constant expression that evaluates to zero be converted to the
null pointer. For example, if we have
int null = 0;
char* p = (char*) null;
there is no guarantee that p will be a null pointer.
Paul is right here. There is also no guarantee that a null pointer
will be converted to 0 when cast to an integer type.
Note that Paul's example is a little misleading however. We also have
char *p = NULL;
assert(p == NULL); // absolutely and always!
long lp = (long)p; // divorced from a pointer context
assert(lp == NULL); // not necessarily...
This should not be surprising since NULL is zero. The standard does
not guarantee in any case that a integer converted to pointer and back
to int will have the same value. For example,
char* p = (char*) 5; // assuming this yields a valid char
// pointer
long lp = (long) p;
assert(lp == 5); // not necessarily.
The standard does guarantee that if long is large enough to hold a
char pointer
char c;
char* p = &c;
long lp = (long) p;
char* q = (char* p);
assert(p == q); //guaranteed
If a pointer is converted to an integer type large enough to hold it
and back to the same pointer type, it will compare equal to the
original pointer.
But even here there is no guarantee that p and q will be represented
by the same bit pattern.
In fact, unless I am missing something, if we have
char* p = NULL;
char* q = NULL;
there is no guarantee that p and q will have the same bit pattern.
Nor can I find any requirement that (long) p == (long) q.
As an aside, for brevity I have used old style casts here. I do not
intend this as an endorsement of such casts; my preference is to
always use new style casts.
--
Michael M Rubenstein
Ron Natalie
>
> Thanks to this thread and mostly to Michael's explanation, my understanding of
> this example is that NULL is an integer (not necessarily int) set to 0.
No, it is an integral CONSTANT with value zero.
Then "long lp = (long)p;"
> promote the "null pointer" to a long integer value. Does not the standard
> impose that promotion of "null pointer" to integer is 0?
The only guarantees is that you can assign a NULL POINTER CONSTANT
to a pointer, which will be distinct from any object and COMPARE
pointers to the NULL POINTER CONSTANT. There are no guarantees
about the conversions of pointers to/from integers other than the
null pointer constant.
jim.h...@leitch.com
"Paul Lutus" <nos...@nosite.com> wrote:
> << I know that in VC++ 5.0, I get undefined pointers that seem to come up
> sometimes as 0xcdcdcdcd >>
>
> This is actually a separate issue, one much easier to explain. If you do not
> assign a value to a pointer, and depending on the (1) compiler, (2)
> platform, and (3) chosen compilation mode, you may see any random value for
> that pointer.
Actually, what he's seeing is VC's debug way of detecting heap errors.
0xcdcdcdcd is the value filled into freshly-allocated memory; when the memory
is deleted, it is filled with 0xfdfdfdfd (or some similarly-detectable
value). But that's wandering into compiler-specific and off-topic areas.
Jim
Note to recruitment agencies: I will not refer my friends or colleagues
to you nor do I want to use your services to find me a job. I stop
reading unsolicited email as soon as I determine it is job-recruitment
-----------== Posted via Deja News, The Discussion Network ==----------
jim.h...@leitch.com
mik...@ix.netcom.com (Michael Rubenstein) wrote:
> On Wed, 10 Feb 1999 14:38:51 GMT, jim.h...@leitch.com wrote:
>
> >In article <36c50cd2....@nntp.ix.netcom.com>,
> > mik...@ix.netcom.com (Michael Rubenstein) wrote:
> >> The C++ standard allows NULL to assume any value it must, as long as
> >> that value is zero and is represented by all zero bits.
> >
> >Wait a second! NULL's physical representation is independent of what
you
> >write.
>
As I acknowledged later in the same message ;-)
> And what color Model T would you like? :-)
Hmm... let's see... black, black or black. I'll take black.
Paul Lutus
else:
<< As about pointer that contains "null-value" - it is also equal to 0 in
all cases >>
This needs clarification. It was only to this that I responded, nothing
else. It won't do for you to try to make my reply more general than I either
intended it or made it.
I didn't object to his assertion that NULL is defined as zero. I only
objected to his assertion that a pointer containing NULL must also equal
zero in all cases. It can be successfully and consistently compared to 0 or
NULL, but that is not the same thing.
Not to beat a dead horse, but do you realize how argumentative your prose
is? One gets the impression that an argument, an adversarial position, is
more important than clarity of expression and producing a concise
description.
You know, not everything in life is optimally based on adversarial
positions, and not all characters in the human drama wear black and white
hats.
Paul Lutus
Michael Rubenstein wrote in message
<36d1ecaf....@nntp.ix.netcom.com>...
>I think we should all acknowledge the great debt we owe Paul in
>destroying this dangerous strawman. It was obvious form mfurman's
>post that he was objecting to the statement that NULL need not be
>zero. If one reads his entire post, he clearly recognizes that the
>bit pattern that represents a null pointer need not be all zero bits.
>He makes it very clear that when he says that a pointer that contains
>null-value equals zero he means that it will compare equal to zero.
>
>Most of us were daunted by the fact that mfurman obviously understands
>null pointers and what NULL is. Faced with someone who was using the
>term NULL as it is defined by the standard, we stood paralyzed.
>Fortunately, Paul had the courage to ignore this and take one of his
>statements out of context so he could destroy the strawman.
>
>We also must admire Pauls chutzpah in citing a page that says that
>NULL should always be zero in defense of his statement that NULL is
>not always zero (actually, the page also allows NULL to be (void*) 0,
>but that is because it is from Steve Summit's excellent C FAQ and
>(void*) 0 is a legal value for NULL in that language).
>--
>Michael M Rubenstein
Michael Rubenstein
wrote:
><< As about pointer that contains "null-value" - it is also equal to 0 in
>all cases >>
>
>The compiler will make sure this appears to be true on all platforms, but a
>debugger, examining a compiled program, may in some cases reveal something
>else, something that is permitted by the standard. And it is possible to
>test for this behavior in source code, without relying on a debugger (some
>may regard that as "cheating"):
>
>char *p = NULL;
>
>assert(p == 0); // absolutely and always!
>
>long lp = (long)p; // divorced from a pointer context
>
>assert(lp == 0); // not necessarily...
>
>My example makes the simplifying, sometimes incorrect assumption that
>sizeof(long) == sizeof (char *).
>
>Yours is the kind of position that, although correct on the surface, is
>misleading if closely examined, and was in fact the genesis of this (overly
>long) thread. Please take the time to read (1) this entire thread, and (2)
>http://www.eskimo.com/~scs/C-faq/q5.5.html.
I think we should all acknowledge the great debt we owe Paul in
Michael Rubenstein
wrote:
>Actually, all your prose aside, I was only addressing this quote, nothing
>else:
>
><< As about pointer that contains "null-value" - it is also equal to 0 in
>all cases >>
>
>This needs clarification. It was only to this that I responded, nothing
>else. It won't do for you to try to make my reply more general than I either
>intended it or made it.
And mfurman did clarify it. You took that out of context. The full
statement was
As about pointer that contains "null-value" - it is also equal
to 0 in all cases (that means that if "p" is a pointer after
either "p = NULL;" or "p = 0;" expression "p == 0" will
evaluate to "true").
I fail to see how it "clarifies" the statement to take part of it out
of context so it seems to say something other than what was intended.
--
Michael M Rubenstein
Andrew Morgan
int *p;
p = new int(87);
if(p)
{
//...
}
else
{
cout << "Allocation error\n";
exit(1);
}
Andrew
BooI...@paradoxoflove.com
<nos...@nosite.com> wrote:
>Are we done now? This thread is getting tiresome.
Now is the time on Shhprockets when we DANCE!
Now, touch my minky!
Anyone can become angry. That is easy. But to be angry with
the right person, to the right degree, at the right time, for the
right purpose and in the right way - that is not easy. - Aristotle
jim.h...@leitch.com
mik...@ix.netcom.com (Michael Rubenstein) wrote:
> On Fri, 12 Feb 1999 23:15:35 -0800, "Paul Lutus" <nos...@nosite.com>
> wrote:
<yawn>
Can you guys take this to email, please?
David A Henry
> But they are!. That is, for all types T,
>
> T* p = NULL;
> if (p == 0)
> cout << "equal" << endl;
> else
> cout << "not equal" << endl;
>
> will print "equal".
Not if "#define NULL 1". Implausible, not impossible.
David A Henry
mailto:dhe...@bigfoot.com
http://www.bigfoot.com/~dhenry
Roel Schroeven
>
> On Thu, 11 Feb 1999, Andrew Koenig wrote:
> > But they are!. That is, for all types T,
> >
> > T* p = NULL;
> > if (p == 0)
> > cout << "equal" << endl;
> > else
> > cout << "not equal" << endl;
> >
> > will print "equal".
>
> Not if "#define NULL 1". Implausible, not impossible.
Impossible. The comp.lang.c FAQ - and I do beleive C and C++ behave the
same on this issue - states very clearly that NULL is defined as 0 or
possibly something like (void*) 0. Certainly not 1.
--
___________________________________________________
| ro...@dekimo.com
| .===,
| : _
| "==____/ `
| <<<<\_,
| Dekimo N.V. Electronics & Software
| Oefenpleinstraat 5
| B-9050 Gentbrugge
| Tel +32 9 231.07.90
| Fax +32 9 231.44.03
Michael Rubenstein
><yawn>
>
>Can you guys take this to email, please?
No we cannot. Or, at least, I cannot as Paul Lutus does not reveal
his email address.
Normally I wouldn't respond to this but since you found it necessary
to post the question 3 days after the last posting from either Paul or
me on this thread, it was clear that you felt it very important to ask
this question and felt you should have an answer.
--
Michael M Rubenstein
Seth Jones
says...
code. This has nothing whatsoever to do with the value of the macro
"NULL". What you are relying on here is the built-in conversion from any
pointer type to bool. A null pointer value will be converted to "false",
but it does not have to be "zero" in any sense.
Besides, the standard behavior of "new" is to throw an exception when it
fails, not to return a null pointer.
Seth Jones
jim.h...@leitch.com
ro...@dekimo.com wrote:
> David A Henry wrote:
> >
> > On Thu, 11 Feb 1999, Andrew Koenig wrote:
> > > But they are!. That is, for all types T,
> > >
> > > T* p = NULL;
> > > if (p == 0)
> > > cout << "equal" << endl;
> > > else
> > > cout << "not equal" << endl;
> > >
> > > will print "equal".
> >
> > Not if "#define NULL 1". Implausible, not impossible.
>
> Impossible. The comp.lang.c FAQ - and I do beleive C and C++ behave the
> same on this issue - states very clearly that NULL is defined as 0 or
> possibly something like (void*) 0. Certainly not 1.
that evaluates to 0. As you say, "Certainly not 1."
Andrew Morgan
> Ummm, you may not have noticed, but NULL doesn't even appear in this
> code.
I agree, but the emphasis of the thread is "is NULL == 0", and if not, the
above test fails. The implicit test of
if(p)
is
if(p != NULL)
but, is it ultimately
if(p != 0) ? <-- This is the issue as I understand it.
> This has nothing whatsoever to do with the value of the macro
> "NULL". What you are relying on here is the built-in conversion from any
> pointer type to bool. A null pointer value will be converted to "false",
> but it does not have to be "zero" in any sense.
My understanding is that false == 0, and true == -1 (0xFFFFFFFF); however, in
terms of testing, anything not false is regarded as true (otherwise, if(p) will
only be true for one address (0xFFFFFFFF)). If NULL is defined as, for
argument's sake, 0x12345678, how will casting this to a bool make it false? If
the above definitions of true and false hold, then this null pointer will cast
to true. What happens with memory allocated at 0x12345678 - has this allocation
failed??
> Besides, the standard behavior of "new" is to throw an exception when it
> fails, not to return a null pointer.
This example comes from Herbert Schildt's "C++: The Complete Reference, 3rd
Edition". According to him, "Like malloc(), new allocates memory from the heap.
It returns a null pointer if there is insufficient memory to fulfill the
allocation request."
One of his big points is that
if(p)
this is much better style than
if(p == NULL) // sense of the test is reversed.
I appreciate that the idea of defining NULL as non-zero in theory is ok, but I
don't see how anything non-zero can actually work in practice. However, the
size of the thread indicates that this is not a cut-and-dried issue.
Andrew Morgan
Andrew Morgan
p = new int(87);
if(p)
> Ummm, you may not have noticed, but NULL doesn't even appear in this
> code. This has nothing whatsoever to do with the value of the macro
> "NULL".
You have hit the nail right on the head! If new fails, it returns NULL, however
the test make no reference to it whatsoever! It is assumed to be 0, otherwise
the test is meaningless.
Andrew Morgan
Seth Jones
says...
does not throw an exception when it fails, "new" does _not_ return NULL.
It returns an implementation defined invalid pointer value (which may
well be nonzero). When you say "if(p)" the pointer gets converted to an
integer, because "if" takes an integer argument, and that conversion
maps the invalid pointer value to zero. The definition of the NULL macro
does not come into the picture.
Seth Jones
Ron Natalie
> does not throw an exception when it fails, "new" does _not_ return NULL.
It returns a "null pointer." This also holds for the STANDARD
new when the non-throwing version is used.
> It returns an implementation defined invalid pointer value (which may
> well be nonzero).
Which the standard calls a null pointer.
> When you say "if(p)" the pointer gets converted to an
> integer, because "if" takes an integer argument, and that conversion
> maps the invalid pointer value to zero.
There is no conversion to zero. If doesn't take an integer.
Conditions are bools. null pointers are converted to false
by definition without any necessity to be converted to integer
zeros or comparisons against null pointer constants.
Andrew J Robb
"The macro NULL is an implementation-defined C++ null pointer constant"
There is nothing here to indicate that NULL is an integer.
Paul Black
4.10:
An integral constant expression (_expr.const_) rvalue of integer type
that evaluates to zero (called a null pointer constant) can be con-
verted to a pointer type.
Paul
Michael Rubenstein
<Andy...@X-Tension.com> wrote:
>ISO/IEC 14882:1998 18.1
>"The macro NULL is an implementation-defined C++ null pointer constant"
>
>There is nothing here to indicate that NULL is an integer.
Except, of course, that the standard requires it. A null pointer
constant is defined as a constant integral expression with value 0.
--
Michael M Rubenstein
Seth Jones
> Andrew J Robb <Andy...@X-Tension.com> wrote:
> >
> > ISO/IEC 14882:1998 18.1
> > "The macro NULL is an implementation-defined C++ null pointer constant"
> >
> > There is nothing here to indicate that NULL is an integer.
>
> An integral constant expression (_expr.const_) rvalue of integer type
> that evaluates to zero (called a null pointer constant) can be con-
> verted to a pointer type.
>
> Paul
>
NULL is a null pointer constant.
0 is a null pointer constant.
Like Andrew said, "There is nothing here to indicate that NULL is an
integer."
If I define
int * const foo = 0;
is foo a null pointer constant? It is certainly a pointer constant. It
is definitely _not_ an integer. Someone care to argue that it is not
"null"? If not, what is it?
Seth Jones
Matt Austern
> If I define
> int * const foo = 0;
> is foo a null pointer constant? It is certainly a pointer constant. It
> is definitely _not_ an integer. Someone care to argue that it is not
> "null"? If not, what is it?
It is a constant pointer, and it is null. It is not a "null pointer
constant" as that phrase is defined in the C++ standard. The phrase
"null pointer constant" has a specific definition: "an integral
constant expression rvalue of integer type that evaluates to zero."
(Section 4.10, paragraph 1)
Michael Rubenstein
wrote:
>In article <36D3F07A...@tcam.com>, paul_...@tcam.com says...
>> Andrew J Robb <Andy...@X-Tension.com> wrote:
>> >
>> > ISO/IEC 14882:1998 18.1
>> > "The macro NULL is an implementation-defined C++ null pointer constant"
>> >
>> > There is nothing here to indicate that NULL is an integer.
>>
>> 4.10:
>> An integral constant expression (_expr.const_) rvalue of integer type
>> that evaluates to zero (called a null pointer constant) can be con-
>> verted to a pointer type.
>>
>> Paul
>>
>
>NULL is a null pointer constant.
>0 is a null pointer constant.
>
>Like Andrew said, "There is nothing here to indicate that NULL is an
>integer."
>
>If I define
>int * const foo = 0;
>is foo a null pointer constant? It is certainly a pointer constant. It
>is definitely _not_ an integer. Someone care to argue that it is not
>"null"? If not, what is it?
No, it is not a null pointer constant. A null pointer constant is not
a pointer it is an integer and always has the value 0. The definition
of a null pointer constant is in 4.10:
A null pointer constant is an integral constant expression
(5.19) rvalue of integer type that evaluates to zero.
--
Michael M Rubenstein
Seth Jones
says...
> >In article <36D3F07A...@tcam.com>, paul_...@tcam.com says...
> >> 4.10:
> >> An integral constant expression (_expr.const_) rvalue of integer type
> >> that evaluates to zero (called a null pointer constant) can be con-
> >> verted to a pointer type.
...
> The definition
> of a null pointer constant is in 4.10:
>
> A null pointer constant is an integral constant expression
> (5.19) rvalue of integer type that evaluates to zero.
(I hope I haven't messed up the attributions somehow)
Hmmm, no wonder I'm confused. Are we dealing with different versions
here or something?
I hope I'm not the only one who thinks it's absurd to call any kind of
"integral expression" a "pointer". If you mean "zero" SAY "zero". This
is supposed to be a formal specification of a computer language, after
all.
Seth Jones
Michael Rubenstein
I cut and pasted my quote from the PDF version of the standard.
--
Michael M Rubenstein