Assigning NULL to a variable (not pointer)

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

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.

 

[Frederick Gotham]

=?ISO-8859-15?Q?Juli=E1n?= Albo posted:

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

 

[Jim Langston]

( title is: Assigning NULL to a variable (not pointer)

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.

 

[Clark S. Cox III]

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]

 

[Ian Collins]

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.

 

[Ron Natalie]

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.

 

[Frederick Gotham]

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

 

[Clark S. Cox III]

Ron Natalie 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);

 

[Frederick Gotham]

Clark S. Cox III posted:

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.

 

[Ron Natalie]

Ron Natalie posted:



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.

 

[Jim Langston]

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.

 

[Ron Natalie]

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.