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

Assigning NULL to a variable (not pointer)

P: n/a
I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?

Oct 16 '06 #1
Share this Question
Share on Google+
31 Replies


P: n/a
le*****@gmail.com wrote:
I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?
<devilsadvocate>

What if nobody besides you think it's a bad practice? And shouldn't
the sheer fact that you can't find any definitive source stating it's
bad tell you that it might not be all that bad? Just asking...

</devilsadvocate>

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 16 '06 #2

P: n/a
Leon posted:
I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?

Imagine two different planets with two totally different species, two
totally different cultures. These two planets don't communicate with each
other as they are unaware of each other's existance.

Give each of them the C++ Standard and a compiler.

One planet will come up with its own ideals and styles, and the other
planet will come up with different ones.

If your question is to do with C++ itself, then the answer is simply this:
Using NULL for zero is harmless, and your compiler won't complain.

If your question is to do with the culture of C++ which exists presently on
Earth, then the answer is: We tend to use NULL only for pointers... and
it's quite irregular to use NULL for integers.

So if you want to fit in, don't use NULL for integers.

If you want to use NULL for integer zero, then go ahead, your compiler
won't complain.

I myself never use NULL.

--

Frederick Gotham
Oct 16 '06 #3

P: n/a
le*****@gmail.com wrote:
I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?
NULL evaluates to a integer constant with value 0. If you want to assign 0,
using 0 is a lot more clear. And if you use 0 not by the numeric value but
as some error/no error flag, the following will be more expressive:

const int MyFuncNoError= 0;

int myfunc ()
{
// ...whatever
return MyFuncNoError;
}

if (myfunc () == MyFuncNoError)

Using NULL you just confuse people by making it to think that myfunc returns
some type of pointer.

Some people use NULL for '\0', probably confusing it with the NUL name of
the char in ascii. This also causes a lot of confusion:

if (somestr != NULL && * somestr != NULL)

Looking at this you can think that somestr is a char * * instead of a char
*.

In a sentence: NULL is intended to be used with pointers, if you use it to
other things you just add confusion and get no benefit.

--
Salu2
Oct 16 '06 #4

P: n/a
First, thats for the replies to this query.

I thought I remembered that in some systems that NULL is not '\0'.
I know that in the majority of systems NULL can equate to '\0', but
I thought there were exceptions and did not what to make any
assumptions.

Not only that, I thought that the definition of NULL was (at least in
some instances): ((void *)0). If one attempted to assign that to an
integer, you would at least get a casting error.

If either the above statements are true, I would think that doing
something like "int var = NULL;" would generally be a bad idea.
Frederick Gotham wrote:
Leon posted:
I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?


Imagine two different planets with two totally different species, two
totally different cultures. These two planets don't communicate with each
other as they are unaware of each other's existance.

Give each of them the C++ Standard and a compiler.

One planet will come up with its own ideals and styles, and the other
planet will come up with different ones.

If your question is to do with C++ itself, then the answer is simply this:
Using NULL for zero is harmless, and your compiler won't complain.

If your question is to do with the culture of C++ which exists presently on
Earth, then the answer is: We tend to use NULL only for pointers... and
it's quite irregular to use NULL for integers.

So if you want to fit in, don't use NULL for integers.

If you want to use NULL for integer zero, then go ahead, your compiler
won't complain.

I myself never use NULL.

--

Frederick Gotham
Oct 16 '06 #5

P: n/a
le*****@gmail.com wrote:

[First, please avoid top-posting]
First, thats for the replies to this query.

I thought I remembered that in some systems that NULL is not '\0'.
I know that in the majority of systems NULL can equate to '\0', but
I thought there were exceptions and did not what to make any
assumptions.
In C++, NULL is *always* a constant integer expression with the value of
zero. The most common definition of NULL that I've seen is simply:

#define NULL 0
Not only that, I thought that the definition of NULL was (at least in
some instances): ((void *)0). If one attempted to assign that to an
integer, you would at least get a casting error.
Not in C++. In C, it is legal for the implementation to define NULL as
(void*)0.
If either the above statements are true, I would think that doing
something like "int var = NULL;" would generally be a bad idea.
"int var = NULL;" *is* bad when considering the generally accepted
conventions. However, there is nothing in the language that makes "int
var = NULL;" illegal. Given that statement, any C++ compiler has to
initialize var to zero.
--
Clark S. Cox III
cl*******@gmail.com
Oct 16 '06 #6

P: n/a
le*****@gmail.com wrote:
I thought I remembered that in some systems that NULL is not '\0'.
NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets the
value '\0' by means of habitual conversions, nothing related with NULL
itself.
Not only that, I thought that the definition of NULL was (at least in
some instances): ((void *)0).
Never in standard C++. Some C compilers do it that way.

--
Salu2
Oct 16 '06 #7

P: n/a
Juli√°n Albo wrote:
le*****@gmail.com wrote:
>I thought I remembered that in some systems that NULL is not '\0'.

NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets the
value '\0' by means of habitual conversions, nothing related with NULL
itself.
NULL could indeed be '\0', but that would have no effect on any
conforming program anyway.
--
Clark S. Cox III
cl*******@gmail.com
Oct 16 '06 #8

P: n/a
le*****@gmail.com wrote:
..
>
I thought I remembered that in some systems that NULL is not '\0'.
I know that in the majority of systems NULL can equate to '\0', but
I thought there were exceptions and did not what to make any
assumptions.
There's no reason why '\0' isn't a valid NULL.
>
Not only that, I thought that the definition of NULL was (at least in
some instances): ((void *)0). If one attempted to assign that to an
integer, you would at least get a casting error.
It can be that in C, it's not allowed in C++.
Oct 16 '06 #9

P: n/a
First, again thank you for your posts.

I believe I got the point about NULL.

Now I ask a favor. I made the mistake of using my GMAIL account to
setup my Google Groups account and the bloody thing dumped my email
address in the postings. I have since taken care of the issue for my
posting, but the responses posted still contain my email. Could you
please delete your postings so that the email sniffers won't find me?
Thank you in advance.

LM
Clark S. Cox III wrote:
JuliŠn Albo wrote:
le*****@gmail.com wrote:
I thought I remembered that in some systems that NULL is not '\0'.
NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets the
value '\0' by means of habitual conversions, nothing related with NULL
itself.

NULL could indeed be '\0', but that would have no effect on any
conforming program anyway.
--
Clark S. Cox III
cl*******@gmail.com
Oct 16 '06 #10

P: n/a

Somebody posted:
I thought I remembered that in some systems that NULL is not '\0'.

It's perfectly acceptable that NULL would not be defined as the following
on a conforming implementation:

#define NULL '\0'

Here are some other legal definitions of it:

#define NULL 0
#define NULL (0)
#define NULL (5-5)
#define NULL (27%4-3)

I know that in the majority of systems NULL can equate to '\0'

NULL _must_ compare equal to '\0'.

if (NULL != '\0') cout << "This is a K++ compiler.";

, but I thought there were exceptions and did not what to make any
assumptions.

Make those assumptions, because there are no exceptions.

Not only that, I thought that the definition of NULL was (at least in
some instances): ((void *)0). If one attempted to assign that to an
integer, you would at least get a casting error.
Try to compile the following with a C++ compiler.

#define NULL ((void*)0)

int main()
{
int *p = 0;
}

Your compiler should explain to you why NULL is _never_ defined in that
way.
If either the above statements are true, I would think that doing
something like "int var = NULL;" would generally be a bad idea.

Well, neither of them _are_ true, so your every implementation should have
no problem with:

int var = NULL;

NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets
the value '\0' by means of habitual conversions, nothing related with
NULL itself.

The character literal, '\0' _always_ evaluates to integer zero. This is how
we can write such portable code as:

void strcpy(char *to, char const *from)
{
while (*to++ = *from++);
}

, therefore it's _not_ just habitual conversion.

NULL must be an integer compile-time constant which evalutes to zero. '\0'
must also be zero.

Therefore, NULL must compare equal to '\0', and furthermore, an implementor
may define NULL as '\0'.

--

Frederick Gotham
Oct 16 '06 #11

P: n/a
ZV**********@spammotel.com wrote:
First, again thank you for your posts.

I believe I got the point about NULL.

Now I ask a favor. I made the mistake of using my GMAIL account to
setup my Google Groups account and the bloody thing dumped my email
address in the postings. I have since taken care of the issue for my
posting, but the responses posted still contain my email. Could you
please delete your postings so that the email sniffers won't find me?
Thank you in advance.
The majority of people here don't use GG and can't delete the postings.
In fact, none of the people responding in this thread besides you use
it. Some newsreaders are able to issue cancel messages, those might or
might not help your situation.

Brian
Oct 16 '06 #12

P: n/a
Frederick Gotham posted:

Try to compile the following with a C++ compiler.

#define NULL ((void*)0)

int main()
{
int *p = 0;
}

int *p = NULL;

--

Frederick Gotham
Oct 16 '06 #13

P: n/a
Frederick Gotham wrote:
>NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets
the value '\0' by means of habitual conversions, nothing related with
NULL itself.

The character literal, '\0' _always_ evaluates to integer zero.
Try this:
cout << '\0' << '\n';
cout << 0 << '\n';

--
Salu2
Oct 16 '06 #14

P: n/a
JuliŠn Albo wrote:
Frederick Gotham wrote:
>>NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets
the value '\0' by means of habitual conversions, nothing related with
NULL itself.
The character literal, '\0' _always_ evaluates to integer zero.

Try this:
cout << '\0' << '\n';
cout << 0 << '\n';
Yeah so what? '\0' is an integer zero.
ostream::operator<< however distinguishes some
integer types (e.g., char) from others (like int).
The same is true for char* versus void*.
Oct 16 '06 #15

P: n/a
=?ISO-8859-15?Q?Juli=E1n?= Albo posted:
Try this:
cout << '\0' << '\n';

Also try it's equivalent:

cout << (char)0 << '\n';

Indeed, std::ostream might define certain overloads for operator<<, but that
doesn't make "char" any less of an integer type, nor its zero value any less
of an integer zero value.

--

Frederick Gotham
Oct 16 '06 #16

P: n/a
Ron Natalie wrote:
>>>NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets
the value '\0' by means of habitual conversions, nothing related with
NULL itself.
The character literal, '\0' _always_ evaluates to integer zero.

Try this:
cout << '\0' << '\n';
cout << 0 << '\n';
Yeah so what? '\0' is an integer zero.
Is an integer type constant, but does not evaluate to nothing but char 0 in
this case.

My first paragraph was confuse, certainly. The point is that even if NULL is
defined as '\0' is not intended to be used like that char literal, but in
contexts where the concrete integer type does not matter. And if is not
defined that way, the char also gets the value '\0', so the definition of
NULL in the implementation is not relevant.

--
Salu2
Oct 16 '06 #17

P: n/a
=?ISO-8859-15?Q?Juli=E1n?= Albo posted:
>Yeah so what? '\0' is an integer zero.

Is an integer type constant, but does not evaluate to nothing but char 0
in this case.

Yes. The following two expressions are exactly equivalent:

(1) '\0'

(2) (char)0
"char" is a fully-fledged integer type in every way.

--

Frederick Gotham
Oct 16 '06 #18

P: n/a
JuliŠn Albo wrote:
Ron Natalie wrote:
>>>>NULL is never '\0', NULL is 0. If you assign 0 to a char the char gets
the value '\0' by means of habitual conversions, nothing related with
NULL itself.
The character literal, '\0' _always_ evaluates to integer zero.
Try this:
cout << '\0' << '\n';
cout << 0 << '\n';
Yeah so what? '\0' is an integer zero.

Is an integer type constant, but does not evaluate to nothing but char 0 in
this case.
char is an integer type.
>
My first paragraph was confuse, certainly. The point is that even if NULL is
defined as '\0' is not intended to be used like that char literal,
So, that wasn't the question. The question was "can NULL be '\0'.
I was refuting the argumnt that quoted above that "NULL is never '\0'"
and that is wrong. The language does not prohibit it.

There's nothing more or less correct about it being '\0' than 0
or 0L or false.
Oct 16 '06 #19

P: n/a
Frederick Gotham wrote:
>>Yeah so what? '\0' is an integer zero.

Is an integer type constant, but does not evaluate to nothing but char 0
in this case.

Yes. The following two expressions are exactly equivalent:

(1) '\0'

(2) (char)0
Yes, both are char constants, and are used like that were appropriate.

--
Salu2
Oct 16 '06 #20

P: n/a
Ron Natalie wrote:
>>>>The character literal, '\0' _always_ evaluates to integer zero.
Try this:
cout << '\0' << '\n';
cout << 0 << '\n';

Yeah so what? '\0' is an integer zero.

Is an integer type constant, but does not evaluate to nothing but char 0
in this case.

char is an integer type.
Yes, is, not "evaluates to".
I was refuting the argumnt that quoted above that "NULL is never '\0'"
and that is wrong. The language does not prohibit it.
It will be less confussing if answering the original message, not a quote of
a quote of it.

--
Salu2
Oct 16 '06 #21

P: n/a
=?ISO-8859-15?Q?Juli=E1n?= Albo posted:
>Yes. The following two expressions are exactly equivalent:

(1) '\0'

(2) (char)0

Yes, both are char constants, and are used like that were appropriate.

Yeah... I think I'll stop talking, looks like all of this is going right over
your head. Either that or you're not very articulate with your words --
(personally I think it's a bit of both).

--

Frederick Gotham
Oct 16 '06 #22

P: n/a
( title is: Assigning NULL to a variable (not pointer)
<le*****@gmail.comwrote in message
news:11*********************@k70g2000cwa.googlegro ups.com...
>I remember that this is a bad practice, but can not find a definitive
resource that states it is bad and why. Can anyone help?
Basically, you're lying about the meaning of the variable then. If I saw
the code:

int MyVar = NULL;

I would immediatly presume that MyVar is being cast to a pointer somewhere
and is not acutally used as an integer. And I would start reading the code
with that in mind.

I once had someone send me some code to review and I saw things such as:

SOCKET MyVar, MyVar2;

and I knew this code had nothing to do with sockets and started searching
the code to see where it used sockets, and never could find it. Then I got
an inspiration, and went to the definition of the SOCKET var and saw that it
was a long unsigned int, and the progrrammer just wanted a long unsigned
int, and since SOCKET was defined as that he used it. He lied in his code,
which only causes confusion.

NULL is just a shortcut for 0 in C++. But we still use NULL instead of 0
because it has a special meaning for us, that it's used for pointers. If
you use NULL for something that's not a pointer, you are saying that somehow
you are going to be using this variable as a pointer. If you're not, don't
use NULL.
Oct 16 '06 #23

P: n/a
ZV**********@spammotel.com wrote:
First, again thank you for your posts.

I believe I got the point about NULL.

Now I ask a favor. I made the mistake of using my GMAIL account to
setup my Google Groups account and the bloody thing dumped my email
address in the postings.
[OT]
I'm generally satisfied with gmail's spam filtering (as you can see, I
use my address in an un-masked form). I wouldn't worry about it too much.
[/OT]
I have since taken care of the issue for my
posting, but the responses posted still contain my email. Could you
please delete your postings so that the email sniffers won't find me?
Thank you in advance.
[OT]
In general, it is not possible to delete posts once they're out on
Usenet. Essentially, any client that gives you the impression that it is
possible is being misleading.
[/OT]

--
Clark S. Cox III
cl*******@gmail.com
Oct 17 '06 #24

P: n/a
ZV**********@spammotel.com wrote:
First, again thank you for your posts.

I believe I got the point about NULL.

Now I ask a favor. I made the mistake of using my GMAIL account to
setup my Google Groups account and the bloody thing dumped my email
address in the postings. I have since taken care of the issue for my
posting, but the responses posted still contain my email. Could you
please delete your postings so that the email sniffers won't find me?
Thank you in advance.
They are more likely to get you from the address books of those poor
saps who have had their outlook address books harvested than from Usenet.

--
Ian Collins.
Oct 17 '06 #25

P: n/a
Jim Langston wrote:
>
int MyVar = NULL;

I would immediatly presume that MyVar is being cast to a pointer somewhere
and is not acutally used as an integer. And I would start reading the code
with that in mind.
There's no guarantee that a int reinterpret_casted to a pointer yields
a null pointer value. You get only two guarantees:

1. A integer constant expression of value zero converts to a null
pointer.

2. A pointer value can be converted to a sufficiently large integer
(if such exists) and back to the original pointer type without
change.
Oct 17 '06 #26

P: n/a
Ron Natalie posted:
There's no guarantee that a int reinterpret_casted to a pointer yields
a null pointer value. You get only two guarantees:

1. A integer constant expression of value zero converts to a null
pointer.

Not quite sure what you're saying, but the following _must_ produce the null
pointer value:

int *p = reinterpret_cast<int*>(0);

The only way to guarantee that you get an arithmetic zero address is to turn
the zero into a non-compile time constant, e.g. use:

0,0

instead of:

0

--

Frederick Gotham
Oct 17 '06 #27

P: n/a
Frederick Gotham wrote:
Ron Natalie posted:
>There's no guarantee that a int reinterpret_casted to a pointer yields
a null pointer value. You get only two guarantees:

1. A integer constant expression of value zero converts to a null
pointer.


Not quite sure what you're saying, but the following _must_ produce the null
pointer value:

int *p = reinterpret_cast<int*>(0);
But the following needn't:

int i = 0;
int *p = reinterpret_cast<int*>(i);

--
Clark S. Cox III
cl*******@gmail.com
Oct 17 '06 #28

P: n/a
Clark S. Cox III posted:
>Not quite sure what you're saying, but the following _must_ produce the
null pointer value:

int *p = reinterpret_cast<int*>(0);

But the following needn't:

int i = 0;
int *p = reinterpret_cast<int*>(i);
Indeed it need not, because it only satisfies one of the requirements:

(1) The expression be of integer type and evaluate to zero.
(2) The expression be a compile-time constant.

Your example would be another method of achieving "address zero". Note,
however, that if you were to make "i" const, then you'd have a null pointer
constant.

--

Frederick Gotham
Oct 17 '06 #29

P: n/a
Frederick Gotham wrote:
Ron Natalie posted:
>There's no guarantee that a int reinterpret_casted to a pointer yields
a null pointer value. You get only two guarantees:

1. A integer constant expression of value zero converts to a null
pointer.


Not quite sure what you're saying, but the following _must_ produce the null
pointer value:

int *p = reinterpret_cast<int*>(0);

What I was referring to was that the previous post mentioned
int v = NULL;
and then mentioned casting that to a pointer, i.e.
int *p = reinterpret_cast<int*>(v);

Which is there are no guarantees (even by your understanding)
>
The only way to guarantee that you get an arithmetic zero address is to turn
the zero into a non-compile time constant, e.g. use:

0,0
Even that doesn't guarantee any specific address.

Oct 17 '06 #30

P: n/a
"Ron Natalie" <ro*@spamcop.netwrote in message
news:45**********************@news.newshosting.com ...
Jim Langston wrote:
>>
int MyVar = NULL;

I would immediatly presume that MyVar is being cast to a pointer
somewhere and is not acutally used as an integer. And I would start
reading the code with that in mind.

There's no guarantee that a int reinterpret_casted to a pointer yields
a null pointer value. You get only two guarantees:

1. A integer constant expression of value zero converts to a null
pointer.

2. A pointer value can be converted to a sufficiently large integer
(if such exists) and back to the original pointer type without
change.
I agree to that, yet I still see unsigned long ints used as pointers in some
code written for Windows.
Oct 17 '06 #31

P: n/a
Jim Langston wrote:
>
I agree to that, yet I still see unsigned long ints used as pointers in some
code written for Windows.

Windows has a type for that actually. They call it DWORD_PTR
which took me a while to realize it isn't a poitner to a DWORD
but a integral type that's big enough to hold either a DWORD
or a pointer. Microsoft had to chase down these when they
went to x64 because they were using DWORD (32 bits) to hold
pointers all over the place in the hideous windows message system.
Oct 17 '06 #32

This discussion thread is closed

Replies have been disabled for this discussion.