By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,820 Members | 1,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,820 IT Pros & Developers. It's quick & easy.

NULL vs. 0

P: n/a
I searched the FAQ on this one, couldn't really find an answer.

Stylistically, is it better to use 0 or NULL?

I know that pre-Standard, 0 was recommended, because some compilers
implemented NULL improperly.

However, 18.1/4(footnote 180) indicates that 0 and 0L are valid NULLs,
while (void*)0 is explicitly invalid.

So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.

Also, did nullptr make it into the C++0x draft?
Jun 21 '06 #1
Share this Question
Share on Google+
37 Replies


P: n/a
>From "The C++ Language":

Zero (0) is an int. Because of standard conversions, 0 can be used as a
constant of any integral, floating-point, pointer, or pointer-to-member
type. The type of zero will be determined by context. Zero will
typically (but not always) be represented by a bit-pattern of all-zeros
of the appropriate size.
No object is allocated with the address of 0. Consequently, 0 acts as a
pointer literal, indicating that the pointer doesn't refer to an
object.
In C, it has been popular to define a macro NULL to represent a zero
pointer. Because of C++'s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems.
red floyd wrote:
I searched the FAQ on this one, couldn't really find an answer.

Stylistically, is it better to use 0 or NULL?

I know that pre-Standard, 0 was recommended, because some compilers
implemented NULL improperly.

However, 18.1/4(footnote 180) indicates that 0 and 0L are valid NULLs,
while (void*)0 is explicitly invalid.

So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.

Also, did nullptr make it into the C++0x draft?


Jun 21 '06 #2

P: n/a
ra****@gmail.com wrote:
red floyd wrote:
I searched the FAQ on this one, couldn't really find an answer.

Stylistically, is it better to use 0 or NULL?

I know that pre-Standard, 0 was recommended, because some compilers
implemented NULL improperly.

However, 18.1/4(footnote 180) indicates that 0 and 0L are valid NULLs,
while (void*)0 is explicitly invalid.

So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.

Also, did nullptr make it into the C++0x draft?

From "The C++ Language":


Zero (0) is an int. Because of standard conversions, 0 can be used as a
constant of any integral, floating-point, pointer, or pointer-to-member
type. The type of zero will be determined by context. Zero will
typically (but not always) be represented by a bit-pattern of all-zeros
of the appropriate size.
No object is allocated with the address of 0. Consequently, 0 acts as a
pointer literal, indicating that the pointer doesn't refer to an
object.
In C, it has been popular to define a macro NULL to represent a zero
pointer. Because of C++'s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems.

1. Please don't top post
(http://www.parashift.com/c++-faq-lit....html#faq-5.4).
Rearranged to conform to c.l.c++ netiquette.

2. I have, and have read TC++PL3e. My point was that because the
Standard 18.1/4 specifies "The macro NULL is an implementation-defined
null pointer constant in this International Standard (4.10)." Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?
Jun 21 '06 #3

P: n/a
red floyd wrote:
...
So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.
...


For that very reason it makes sense to prefer NULL over 0 in pointer context.
Otherwise, they are equivalent (in such contexts).

--
Best regards,
Andrey Tarasevich
Jun 21 '06 #4

P: n/a
* red floyd:
Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?


NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.

When maintaining or adding to some existing code base, I think it would
be prudent to follow the conventions already established in that code.

Otherwise, I can't see much for or against any particular practice,
except that consistency is generally good, and except that I think it
would be ungood to mislead by using NULL for integer 0 or struct for a
very non-POD, non-aggregate class.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 21 '06 #5

P: n/a
Andrey Tarasevich wrote:
red floyd wrote:
...
So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.
...


For that very reason it makes sense to prefer NULL over 0 in pointer context.
Otherwise, they are equivalent (in such contexts).


Thanks Alf and Andrey. As I said, the 0 habit was from pre-Standard
days, based on old versions of TCPPPL (1st and 2nd editions!!!).

Just curious about prevailing style.

Thanks again!
Jun 22 '06 #6

P: n/a

red floyd wrote:

2. I have, and have read TC++PL3e. My point was that because the
Standard 18.1/4 specifies "The macro NULL is an implementation-defined
null pointer constant in this International Standard (4.10)." Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?


You are asking why someone would *still* use 0 instead of NULL, as if
NULL was somehow better (ie maybe more descriptive).

I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?

By the way, here is a 'gotcha' against using NULL, specifically with
regards to NULL being (incorrectly!) perceived as a null pointer:

void func(int x); // A
void func(char *ptr); // B

void foo()
{
func(NULL); // [1]
func(0); // [2]
}

At [1] which func is called, 'A' or 'B'? What about at [2]?

the 'gotcha' may seem obvious in this example, but when you are
debugging a bunch of code, I prefer to see what is really going on - 0,
not NULL.

Tony

P.S. macros are evil.

Jun 22 '06 #7

P: n/a
gottlobfrege wrote:
I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?
NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.

Using 0 just because "the Standard permits it" is sophomoric pedantry.
By the way, here is a 'gotcha' against using NULL, specifically with
regards to NULL being (incorrectly!) perceived as a null pointer:

void func(int x); // A
void func(char *ptr); // B
The guidelines against gratuitous overloads also apply here...
P.S. macros are evil.


So are 'if' statements, 'goto', 'cout', and anything else that can be
abused.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 22 '06 #8

P: n/a
Phlip wrote:
gottlobfrege wrote:
I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?
NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.


That's self-contradictory. NULL is an integer, but one usually thinks of it
as a pointer, because it is only used in pointer context. So using NULL to
hide the fact that you have an integer is less clear than directly using 0.
Using 0 just because "the Standard permits it" is sophomoric pedantry.


I would say the same about using NULL just because the Standard inherited it
from C.

Jun 22 '06 #9

P: n/a
In article <R4******************@newssvr14.news.prodigy.com >,
"Phlip" <ph******@yahoo.com> wrote:
NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.

Using 0 just because "the Standard permits it" is sophomoric pedantry.


Also, I can easily search for the string NULL in my source code. You don't
realize how important stuff like that is until you've got a million lines
of source code to slog trough trying to find constructs which might tickle
some new compiler bug that was just discovered.
Jun 22 '06 #10

P: n/a
Roy Smith wrote:
Also, I can easily search for the string NULL in my source code. You
don't realize how important stuff like that is until you've got a million
lines of source code to slog trough trying to find constructs which might
tickle some new compiler bug that was just discovered.


You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 22 '06 #11

P: n/a

red floyd wrote:
Andrey Tarasevich wrote:
red floyd wrote:
...
So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.
...
For that very reason it makes sense to prefer NULL over 0 in pointer context.
Otherwise, they are equivalent (in such contexts).


Thanks Alf and Andrey. As I said, the 0 habit was from pre-Standard
days, based on old versions of TCPPPL (1st and 2nd editions!!!).

Just curious about prevailing style.


The prevailing style is that it is a religious debate similar to where
you put your brackets, only the case of null, the standard is working
on resolving the debate.

Thanks again!


Jun 22 '06 #12

P: n/a
Rolf Magnus wrote:
Use NULL to state your intent as clearly and prouncably as possible.


That's self-contradictory. NULL is an integer, but one usually thinks of
it
as a pointer, because it is only used in pointer context. So using NULL to
hide the fact that you have an integer is less clear than directly using
0.


http://groups.google.com/groups/search?q=kanze+null

If you think you have a stand here, you owe Kanze a post. ;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 22 '06 #13

P: n/a
JuliŠn Albo wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }


You have two typographical errors there. Allow me to fix them:

.... urn static_cast <T *> (NULL); }
.... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 22 '06 #14

P: n/a
gottlobfrege wrote:
The prevailing style is that it is a religious debate similar to where
you put your brackets, only the case of null, the standard is working
on resolving the debate.


Part of learning C++ is learning which style issues are really technical
issues. {} is style. NULL is technical.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 22 '06 #15

P: n/a

Alf P. Steinbach wrote:
* red floyd:
Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?


NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.


A rather disagree that struct indicates POD. It is an artificial
indicator at best, one easily broken as the language makes no such
distinction. I don't think this is something that can be depended on
at all and therefore is no indicator that we have a POD vs. non-POD.

Jun 22 '06 #16

P: n/a
Phlip wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }


You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.


We can make another enhancement:

template <class T> bool isNull (T * ptr) { return isNull (ptr); }

Much more readable this way X-)

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 22 '06 #17

P: n/a
In message <Nt*******************@newssvr11.news.prodigy.com> , Phlip
<ph******@yahoo.com> writes
JuliŠn Albo wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }
You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

And now to get the definition of NULL you have to #include some huge
header file in something which is itself going to be included all over
the place.
Aah, much more readable and pronouncable.

Who wants to do either?

--
Richard Herring
Jun 22 '06 #18

P: n/a

go**********@gmail.com wrote:
red floyd wrote:

2. I have, and have read TC++PL3e. My point was that because the
Standard 18.1/4 specifies "The macro NULL is an implementation-defined
null pointer constant in this International Standard (4.10)." Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?
You are asking why someone would *still* use 0 instead of NULL, as if
NULL was somehow better (ie maybe more descriptive).

I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?

There are several good reasons.
The best one : It is more human-friendly... You know the intent of the
programmer (assuming that the programmer uses NULL in pointer contexts
only).
But there are other reasons.
For instance, with Borland C++ 5.0 (for x86 CPU), in 16 bits real mode,
the definition of NULL depends on the memory model.
For memory models where pointers are 16 bits large (tiny, small,
medium), NULL is 0 (and int are 16 bits)
For memory models where pointers are 32 bits (compact, large, huge),
NULL is 0L (and long are 32 bits)
On this platform, the representation for the NULL pointer is
all-bits-zero, which is the same representation than the 0 integer
constant (both signed and unsigned).
Using NULL, can avoid bad behaviors in UB contexts.
For instance:
printf("%p", NULL); /* Undefined behavior : But works "as expected"
with Borland C++ */

P.S. macros are evil.


Even if the standard says that NULL is a macro, it can be a "harmless"
macro.
i.e., it can be implemented as:

/* dummy macro definition */
#define NULL NULL
const int NULL=0;
I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.

I can think of very very old implementations of C, where "char*" and
"int" appeared to be almost semantically equivalent (because the
compiler did very very bad type checking, and dereferencing int was
"accepted" by the compiler).
But, it would be a very bad idea to use one type for the other.

Jun 22 '06 #19

P: n/a
Phlip wrote:
JuliŠn Albo wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }


You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.


Chutzpah, man! You make a great point here. The hairs remain unsplit.
Jun 22 '06 #20

P: n/a
SuperKoko wrote:
I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?
There are several good reasons.
The best one : It is more human-friendly... You know the intent of the
programmer (assuming that the programmer uses NULL in pointer contexts
only).


I think that NULL is human-unfriendly precisely because that: I have seen a
lot of code where people mixes NULL used as pointer and used as char (I
suppose they suffer a confusion with the ascii NUL char name). Some people
even write things like:

char * txt;
(...)
if (txt == NULL || txt [0] == NULL)
I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.


The point of type safety is that the compiler can help to avoid some
mistakes. As my previous paragraph shows, NULL does not prevent some
obvious mistakes. It even help create new ones because of the name
confusion with NUL.

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 22 '06 #21

P: n/a
* Noah Roberts:
Alf P. Steinbach wrote:
* red floyd:
Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?

NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.


A rather disagree that struct indicates POD. It is an artificial
indicator at best, one easily broken as the language makes no such
distinction. I don't think this is something that can be depended on
at all and therefore is no indicator that we have a POD vs. non-POD.


Whether struct indicates POD depends on your conventions.

Be aware that struct indicates POD to many people.

Except in short example code.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 22 '06 #22

P: n/a

Alf P. Steinbach wrote:
* Noah Roberts:
Alf P. Steinbach wrote:
* red floyd:
Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?
NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.
A rather disagree that struct indicates POD. It is an artificial
indicator at best, one easily broken as the language makes no such
distinction. I don't think this is something that can be depended on
at all and therefore is no indicator that we have a POD vs. non-POD.


Whether struct indicates POD depends on your conventions.


Conventions like that are unenforceable at best. It is also a rather
silly distinction to make especially in light of tr1 and type traits.
Algorithms can be designed to take advantage of PODS in whatever form
they take when necissary (yes, classes can be PODS as you well know).

struct being a POD is a bastard child of C. It is a concept best
forgotten. The struct keyword is a poor indicator of PODness that has
no basis in the language.
Be aware that struct indicates POD to many people.
Well many people do silly things all the time. Those assumptions are
invalid and shouldn't be made. The fact that most people do has no
impact on the validity of the claim.
Except in short example code.


Size of the code doesn't really matter except that altering a struct to
become a class, just to match some silly idea that structs are PODS
only, in a large project is just crazy. If some struct suddenly needs
a constructor or virtual function then add it...don't do a bunch of
pointless work to make it use the class keyword instead of struct.

Simply put, this "convention" can't be depended on even if it is a
convention. You'll spend more time trying to hold to it than there is
any benifit in doing so. You'll also spend a lot of time trying to
enforce this artificial constraint for every new person comming in that
is not aware of or doesn't understand the distinction...and the later
is easy to see happening since there isn't one.

Jun 22 '06 #23

P: n/a
JuliŠn Albo wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.


except for the part about your code not compiling anymore. :)

template <class T> T *NullPtr() { return static_cast <T *>(0); }
struct str {
int a;
};
void foo() {
int *i = NullPtr();
str *s = NullPtr();
}

g++ -c t.cc
t.cc: In function 'void foo()':
t.cc:6: error: no matching function for call to 'NullPtr()'
t.cc:7: error: no matching function for call to 'NullPtr()'

Jun 22 '06 #24

P: n/a
tedu <tu@zeitbombe.org> wrote:
JuliŠn Albo wrote:
template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.

except for the part about your code not compiling anymore. :)
It will, if used correctly:
template <class T> T *NullPtr() { return static_cast <T *>(0); }
struct str {
int a;
};
void foo() {
int *i = NullPtr();
int* i = NullPtr <int> ();
str *s = NullPtr();

str* s = NullPtr <str> ();
}


regards
--
jb

(reply address in rot13, unscramble first)
Jun 22 '06 #25

P: n/a
SuperKoko wrote:
I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.


Yes, and that's exactly the problem, though I would turn that sentence
around:

Even though programmers often do make a difference between NULL and 0,
compilers don't.

Jun 22 '06 #26

P: n/a
tedu wrote:
Juli√°n Albo wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.
except for the part about your code not compiling anymore. :)


It does not compile because you are trying to use it in a non-typesafe way.
template <class T> T *NullPtr() { return static_cast <T *>(0); }
struct str {
int a;
};
void foo() {
int *i = NullPtr();
str *s = NullPtr();
}

g++ -c t.cc
t.cc: In function 'void foo()':
t.cc:6: error: no matching function for call to 'NullPtr()'
t.cc:7: error: no matching function for call to 'NullPtr()'


Jun 22 '06 #27

P: n/a
tedu wrote:
You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.


except for the part about your code not compiling anymore. :)


*Your* code does not compile. Mine does.

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 22 '06 #28

P: n/a
Jakob Bieling wrote:
tedu <tu@zeitbombe.org> wrote:
JuliŠn Albo wrote:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.

except for the part about your code not compiling anymore. :)


It will, if used correctly:
int *i = NullPtr();


int* i = NullPtr <int> ();


ok, now it really seems like a nuisance to use (for me). i had
misinterpreted the intent was almost more like a drop in NULL
replacement of some sort. this clears up some of the why, thanks.

Jun 22 '06 #29

P: n/a
I V
On Thu, 22 Jun 2006 14:19:13 -0700, tedu wrote:
ok, now it really seems like a nuisance to use (for me). i had
misinterpreted the intent was almost more like a drop in NULL
replacement of some sort. this clears up some of the why, thanks.


If you don't want to explicitly specify the type of the null (and I can't
immediately think why you _would_ want that), you could do:

class null_type
{
public:
template<typename T>
operator T*() const
{
return 0;
}
};

const null_type nullptr = null_type();

Jun 23 '06 #30

P: n/a
Rolf Magnus wrote:
SuperKoko wrote:
I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.


Yes, and that's exactly the problem, though I would turn that sentence
around:

Even though programmers often do make a difference between NULL and 0,
compilers don't.


That's not quite true. If I compile

#include <cstddef>

int main()
{
return NULL;
}

I get:

nullptr.cpp: In function 'int main()':
nullptr.cpp:5: warning: converting to non-pointer type 'int' from NULL

so it's a quality of implementation issue.

Jun 23 '06 #31

P: n/a

Markus Schoder wrote:
Rolf Magnus wrote:
SuperKoko wrote:
I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.


Yes, and that's exactly the problem, though I would turn that sentence
around:

Even though programmers often do make a difference between NULL and 0,
compilers don't.


That's not quite true. If I compile

#include <cstddef>

int main()
{
return NULL;
}

I get:

nullptr.cpp: In function 'int main()':
nullptr.cpp:5: warning: converting to non-pointer type 'int' from NULL

so it's a quality of implementation issue.


Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.

Jun 23 '06 #32

P: n/a
Noah Roberts wrote:
> Even though programmers often do make a difference between NULL and 0,
> compilers don't.


That's not quite true. If I compile

#include <cstddef>

int main()
{
return NULL;
}

I get:

nullptr.cpp: In function 'int main()':
nullptr.cpp:5: warning: converting to non-pointer type 'int' from NULL

so it's a quality of implementation issue.


Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.


So? That's what the compiler does in the above case. It just warns that NULL
was used in an integer context. I don't think the standard disallows that.

Jun 23 '06 #33

P: n/a
Rolf Magnus wrote:
Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.


So? That's what the compiler does in the above case. It just warns that
NULL
was used in an integer context. I don't think the standard disallows that.


Would cstddef violate the Standard if it presented this?

#define ((void*)0)

That appears to be what it's doing, and it's not an integral constant, it's
a constant address.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 23 '06 #34

P: n/a

Phlip wrote:
Rolf Magnus wrote:
Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.


So? That's what the compiler does in the above case. It just warns that
NULL
was used in an integer context. I don't think the standard disallows that.


Would cstddef violate the Standard if it presented this?

#define ((void*)0)


That is a certain violation of the C++ standard. The C++ standard
explicitly states that it is not that.

Is the implementation free to display diagnostics about things that are
well formed?

Jun 23 '06 #35

P: n/a
Phlip wrote:
Rolf Magnus wrote:
Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.
So? That's what the compiler does in the above case. It just warns that
NULL
was used in an integer context. I don't think the standard disallows
that.


Would cstddef violate the Standard if it presented this?

#define ((void*)0)


ITYM:

#define NULL ((void*)0)

That would be a violation.
That appears to be what it's doing, and it's not an integral constant,
it's a constant address.


That's not what the compiler (probably gcc) is doing. On my system, NULL is
defined as:

#define NULL (__null)

with __null being a built-in integer constant that resolves to 0, but
generates a compiler warning if used in an integer context.

Jun 23 '06 #36

P: n/a
Noah Roberts wrote:
Phlip wrote:
Rolf Magnus wrote:
>> Hmmm...I think that actually violates the standard. NULL is defined
>> as a macro resolving to a "null pointer constant", which is defined as
>> an "integral constant" resolving to 0.
>
> So? That's what the compiler does in the above case. It just warns that
> NULL
> was used in an integer context. I don't think the standard disallows
> that.
Would cstddef violate the Standard if it presented this?

#define ((void*)0)


That is a certain violation of the C++ standard. The C++ standard
explicitly states that it is not that.


That would be a violation and that is not what the compiler does. It uses
some compiler trickery that is otherwise transparent to the user.
Is the implementation free to display diagnostics about things that are
well formed?


Aren't warnings pretty much always about well-formed constructs? If it
weren't well-formed it would have to be an error.

Jun 23 '06 #37

P: n/a
Noah Roberts wrote:
...
Is the implementation free to display diagnostics about things that are
well formed?
...


Of course. That's what warnings are in a traditional implementation:
diagnostic messages about things that are well-formed.

--
Best regards,
Andrey Tarasevich
Jun 24 '06 #38

This discussion thread is closed

Replies have been disabled for this discussion.