468,491 Members | 1,991 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

NULL==0?

Hi,

Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

Thank you,
Q
Oct 10 '06 #1
20 3465

"Quantum" <no*****@address.comwrote in message
news:6N******************@newsfe1-gui.ntli.net...
Hi,

Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

Thank you,
Q
Although it's from the C faq it addresses your question
http://c-faq.com/null/index.html

Serafeim
Oct 10 '06 #2
Papastefanos Serafeim wrote:
"Quantum" <no*****@address.comwrote in message
news:6N******************@newsfe1-gui.ntli.net...
>Hi,

Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

Thank you,
Q

Although it's from the C faq it addresses your question
http://c-faq.com/null/index.html

Serafeim

Ok, thanks. :)
Q
Oct 10 '06 #3
Quantum wrote:
Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}
yes, but, since text is an array it can never be NULL...
--
Nick Keighley

Oct 10 '06 #4
Nick Keighley wrote:
Quantum wrote:
>Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

yes, but, since text is an array it can never be NULL...

Quantum wrote:
>Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

yes, but, since text is an array it can never be NULL...

Good point! I'm passing text[] into a function, however it is still
declared as a pointer. :)
Oct 10 '06 #5
Quantum wrote:
Hi,

Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}
Strictly speaking they are equivalent, but idiomatically, the use of the
NULL macro indicates that you are evaluating a pointer, and not just
evaluating some integer.

Comparing to NULL and comparing to an integer value of zero are
equivalent in you example, but they are not equivalent everywhere NULL
may be used. This is because NULL does not require a typecast in order
to be passed as a parameter to a function that expects a pointer, but a
plain int would not necessarily satisfy the type requirements of the
function prototype. You might still get away with this, because all
your target platforms probably really do have a NULL pointer that is an
integer value with "all bits off", and all your target platforms
probably really do represent the integer value of zero as a two's
complement number with "all bits off." But, this is really just a happy
coincidence. What happens on a platform where "zero" is something else?
How about on a one's complement system where there are TWO zeros? And
what happens on a platform where the NULL pointer, while represented in
the high level language as "zero", really is some other value, like the
address of some hardware trap with a segment and offset value, different
for each program?

So, this doesn't happen on x86, Sparc, ARM, MIPS, PPC, 68K, or any other
machine you are likely to be using. And maybe it's irrelevant to ask if
you'd bet your life on it remaining so. But it is nonetheless
appropriate to practice the good habit of using the NULL macro for the
null pointer.

Oct 11 '06 #6
jmcgill wrote:
Quantum wrote:
>Hi,

Are these equivalent:

char text[];

if(text==NULL){}
if(text==0){}

Strictly speaking they are equivalent, but idiomatically, the use of the
NULL macro indicates that you are evaluating a pointer, and not just
evaluating some integer.

Comparing to NULL and comparing to an integer value of zero are
equivalent in you example, but they are not equivalent everywhere NULL
may be used. This is because NULL does not require a typecast in order
to be passed as a parameter to a function that expects a pointer, but a
plain int would not necessarily satisfy the type requirements of the
function prototype. You might still get away with this, because all
your target platforms probably really do have a NULL pointer that is an
integer value with "all bits off", and all your target platforms
probably really do represent the integer value of zero as a two's
complement number with "all bits off." But, this is really just a happy
coincidence. What happens on a platform where "zero" is something else?
How about on a one's complement system where there are TWO zeros? And
what happens on a platform where the NULL pointer, while represented in
the high level language as "zero", really is some other value, like the
address of some hardware trap with a segment and offset value, different
for each program?

So, this doesn't happen on x86, Sparc, ARM, MIPS, PPC, 68K, or any other
machine you are likely to be using. And maybe it's irrelevant to ask if
you'd bet your life on it remaining so. But it is nonetheless
appropriate to practice the good habit of using the NULL macro for the
null pointer.
Actually, IIRC, assigning or initializing a pointer type to zero is
defined to produce a null pointer. So, in the case above, 0 would be
promoted to a char* and become a null char*, regardless of the
implementation's actual representation of null pointers. I could be
wrong, but I don't think I am.

Nate
Oct 12 '06 #7
jmcgill wrote:
Strictly speaking they are equivalent, but idiomatically, the use of the
NULL macro indicates that you are evaluating a pointer, and not just
evaluating some integer.
Well many people use the idiomatic zero constant expression for the
null pointer, so you've got no guarantee.
This is because NULL does not require a typecast in order
to be passed as a parameter to a function that expects a pointer, but a
plain int would not necessarily satisfy the type requirements of the
function prototype.
A plain int must be cast, but a NULL POINTER CONSTANT, such as the naked
zero there behaves exactly the same as NULL.
You might still get away with this, because all
your target platforms probably really do have a NULL pointer that is an
integer value with "all bits off",
It's got absolutely nothing to do with the representation of the
pointer. The null pointer constant, defined to be an integral constant
expression evaluating to zero, converts to a pointer type. Any other
integer value, regardless of the format of pointers on your machine,
will NOT convert implicitly. The program is ill-formed IN ALL CASES
if you pass a non-null pointer constant integer value.

The only way you even begin to having to think about what the null
pointer representation is, is when you use a reinterpret cast or
some other non-type safe bashing of the zero value into a pointer.
So, this doesn't happen on x86, Sparc, ARM, MIPS, PPC, 68K, or any other
machine you are likely to be using.
If you're going to bet your life on anything, you might try learning
some of the fundamental concepts of the language.
Oct 12 '06 #8
Quantum wrote:
Nick Keighley wrote:
Quantum wrote:
Are these equivalent:

char text[];
This is a syntax error
Good point! I'm passing text[] into a function, however it is still
declared as a pointer. :)
It isn't declared as anything because your attempted declaration
is a syntax error. A pointer declaration would be:

char *text;

or an array declaration would be:

char text[1];

or some other number instead of 1.

Oct 12 '06 #9
jmcgill wrote:
Strictly speaking they are equivalent, but idiomatically, the use of the
NULL macro indicates that you are evaluating a pointer, and not just
evaluating some integer.
Idiomatically, I like to use if(!ptr) because it looks the same as if
it was a boolean, and it makes sense to me: "if not ptr" is like "if
there's nothing in ptr" or "if ptr is not pointing to anything".
Comparing to NULL and comparing to an integer value of zero are
equivalent in you example, but they are not equivalent everywhere NULL
may be used.
They are always equivalent. It's guaranteed by the standard.
This is because NULL does not require a typecast in order
to be passed as a parameter to a function that expects a pointer, but a
plain int would not necessarily satisfy the type requirements of the
function prototype.
NULL cannot be defined as anything else than zero in C++ so that is
incorrect. NULL is the same as plain 0 as far as overloading is
concerned.
You might still get away with this, because all
your target platforms probably really do have a NULL pointer that is an
integer value with "all bits off", and all your target platforms
probably really do represent the integer value of zero as a two's
complement number with "all bits off." But, this is really just a happy
coincidence. What happens on a platform where "zero" is something else?
How about on a one's complement system where there are TWO zeros? And
what happens on a platform where the NULL pointer, while represented in
the high level language as "zero", really is some other value, like the
address of some hardware trap with a segment and offset value, different
for each program?
You're confusing stuff. In a C++ program the constant 0 IS the null
pointer. It doesn't matter what the representation of it is in the
hardware. If you use 0 in a pointer expression it will have the correct
representation. This is NOT the same as memcmp-ing with zero or
memset-ing a pointer to zero.
So, this doesn't happen on x86, Sparc, ARM, MIPS, PPC, 68K, or any other
machine you are likely to be using. And maybe it's irrelevant to ask if
you'd bet your life on it remaining so. But it is nonetheless
appropriate to practice the good habit of using the NULL macro for the
null pointer.
Talk for yourself. IMO, it is not a good habit to use any unnecessary
macro, which NULL is. NULL is a historical accident like several other
things in the language.

Regards,
Bart.

Oct 13 '06 #10
What about 0x0? I used to use that for pointers since, for me, is a
address and points out that you don't set a value to zero but and
address.

If now NULL is not guarnteed to be zero on some systems would then if (
!ptr ) work? Since false is 0.

Those of you that does this as professionals, what are the corporate
standard on this? Im guessing NULL.

Oct 14 '06 #11
TiraX posted:
What about 0x0?

0x0 is a integer literal. Its type is "int", and its value is zero.

Compile-time integer constants (such as 0x0) which evaluate to zero can
play the part of the null pointer constant in the great play which is C++.

I used to use that for pointers since, for me, is a address and points
out that you don't set a value to zero but and address.

Warped way of looking at it, in my opinion.

If now NULL is not guarnteed to be zero on some systems would then if (
!ptr ) work? Since false is 0.

The macro, NULL, must be a compile-time integer constant which evaluates to
zero. No more. No less.

When a pointer is converted to a boolean, (be it implicitly or explicitly),
the resultant value is false if the pointer held the null pointer value.

The unary boolean inversion operator, "!", takes an operand of type,
"bool", and so the pointer must be converted to a bool. "if (ptr)" will
work as expected on every implementation.

(I ommited the word, "conforming", before "implementation" because it's
redundant in the context of this newsgroup.)
Those of you that does this as professionals, what are the corporate
standard on this? Im guessing NULL.

I myself use 0 when I'm setting its value:

int *p = 0;

, although I rely on simple implicit conversion to bool elsewhere:

if (p) ...

If "nullptr" makes it in, I'll probably start using it, although I'll
continue to use the implicit bool conversion.

--

Frederick Gotham
Oct 14 '06 #12
TiraX wrote:
What about 0x0? I used to use that for pointers since, for me, is a
address and points out that you don't set a value to zero but and
address.
(0x0), (00) and (0) all mean exactly the same thing in every situation.
If now NULL is not guarnteed to be zero on some systems would then if (
!ptr ) work? Since false is 0.
A NULL pointer will always compare equal to zero. What might not be
zero is it's *representation*.
Those of you that does this as professionals, what are the corporate
standard on this? Im guessing NULL.
--
Clark S. Cox III
cl*******@gmail.com
Oct 14 '06 #13
Frederick Gotham wrote:
>
The macro, NULL, must be a compile-time integer constant which evaluates to
zero. No more. No less.
Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.

For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.

Oct 14 '06 #14
Old Wolf posted:
Frederick Gotham wrote:
>>
The macro, NULL, must be a compile-time integer constant which
evaluates to zero. No more. No less.

Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.

For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.
C.2.2.3 Macro NULL [diff.null] 1 The macro NULL, defined in any of
<clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, or
<cwchar>, is an implementation-defined C + + null pointer constant in this
International Standard (18.1).

4.10 Pointer conversions [conv.ptr] 1 A null pointer constant is an
integral constant expression (5.19) rvalue of integer type that evaluates
to zero.

--

Frederick Gotham
Oct 14 '06 #15
Old Wolf wrote:
Frederick Gotham wrote:
>The macro, NULL, must be a compile-time integer constant which evaluates to
zero. No more. No less.

Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.

For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.
__nullptr in GCC is still a constant integer expression that evaluates
to zero. Were it not, it could not be a null pointer constant.

--
Clark S. Cox III
cl*******@gmail.com
Oct 15 '06 #16
Old Wolf wrote:
Frederick Gotham wrote:
>The macro, NULL, must be a compile-time integer constant which evaluates to
zero. No more. No less.

Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.
No, it must be an integral constant expression evaluating
to zero.
>
For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.
GCC is doing this as an extension to the language.

Oct 15 '06 #17
Clark S. Cox III wrote:
Old Wolf wrote:
>Frederick Gotham wrote:
>>The macro, NULL, must be a compile-time integer constant which evaluates to
zero. No more. No less.
Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.

For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.

__nullptr in GCC is still a constant integer expression that evaluates
to zero. Were it not, it could not be a null pointer constant.
Actually, it isn't. It's technically illegal for NULL to be defined
that way, but unless you are abusing NULL, you'd never know.

int x = __nullptr;

is an error in GCC.
Oct 15 '06 #18
Ron Natalie wrote:
Clark S. Cox III wrote:
>Old Wolf wrote:
>>Frederick Gotham wrote:
The macro, NULL, must be a compile-time integer constant which
evaluates to
zero. No more. No less.

Not true. It could be anything as long as it can be converted
to a pointer, resulting in a null pointer.

For example, GCC defines NULL as __nullptr, which is a value
that meets this requirement. This definition does not break
any standards conformance.

__nullptr in GCC is still a constant integer expression that evaluates
to zero. Were it not, it could not be a null pointer constant.

Actually, it isn't. It's technically illegal for NULL to be defined
that way, but unless you are abusing NULL, you'd never know.

int x = __nullptr;

is an error in GCC.
No, it is not (Have you tried it?).

Any compiler that rejects the following program is broken. Period.

#include <cstdlib>

int main()
{
int i = NULL;
return NULL;
}

GCC *will* give a warning (not an error) for the following program.
Again, this is a program that *any* C++ compiler *must* accept:

#include <cstdlib>

int main()
{
int i = NULL + 5; //"warning: NULL used in arithmetic"
return NULL;
}
--
Clark S. Cox III
cl*******@gmail.com
Oct 15 '06 #19
Clark S. Cox III wrote:
GCC *will* give a warning (not an error) for the following program.
Again, this is a program that *any* C++ compiler *must* accept:\
Warning, error...depends on the compiler switch.
>
Oct 16 '06 #20
Ron Natalie wrote:
Clark S. Cox III wrote:
>GCC *will* give a warning (not an error) for the following program.
Again, this is a program that *any* C++ compiler *must* accept:\

Warning, error...depends on the compiler switch.
Conforming, non-conforming ... depends on the compiler switch. If it's a
warning, then the compiler is conforming. If it is an error (that causes
the compiler to reject the code) then the compiler is non-conforming.

I'll reiterate. Any compiler that rejects either of the following
programs is non-conforming:

#include <cstdlib>

int main()
{
int i = NULL;
return NULL;
}

//End program 1

#include <cstdlib>

int main()
{
int i = NULL + 5; //"warning: NULL used in arithmetic"
return NULL;
}

--
Clark S. Cox III
cl*******@gmail.com
Oct 16 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

26 posts views Thread by Agoston Bejo | last post: by
3 posts views Thread by iStrain | last post: by
5 posts views Thread by Mike MacSween | last post: by
3 posts views Thread by sathyashrayan | last post: by
102 posts views Thread by junky_fellow | last post: by
29 posts views Thread by Jason Curl | last post: by
5 posts views Thread by David Sworder | last post: by
64 posts views Thread by yossi.kreinin | last post: by
reply views Thread by Aaron Morton | last post: by
46 posts views Thread by lovecreatesbea... | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by theflame83 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.