NULL==0?

[Quantum]

Hi,

Are these equivalent:

char text[];

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

Thank you,
Q

 

[Papastefanos Serafeim]

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]

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]

Are these equivalent:

char text[];

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

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

 

[Quantum]

Are these equivalent:

char text[];

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

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

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]

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]

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]

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]

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]

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.

 

[TiraX]

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.

 

[Frederick Gotham]

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.

 

[Clark S. Cox III]

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*.

 

[Old Wolf]

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.

 

[Frederick Gotham]

Old Wolf posted:

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.

 

[Clark S. Cox III]

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.

 

[Ron Natalie]

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.

 

[Ron Natalie]

__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.

 

[Clark S. Cox III]

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;
}

 

[Ron Natalie]

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.