NULL==0?

[Quantum]

Hi,

Are these equivalent:

char text[];

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

Thank you,
Q

[Papastefanos Serafeim]

"Quantum" <no*****@addres s.comwrote in message
news:6N******** **********@news fe1-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

[Quantum]

Papastefanos Serafeim wrote:

"Quantum" <no*****@addres s.comwrote in message
news:6N******** **********@news fe1-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

[Nick Keighley]

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

[Quantum]

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. :)

[jmcgill]

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.

[Nate Barney]

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

[Ron Natalie]

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.

[Old Wolf]

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.

[Bart]

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.