«

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

=?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

( title is: Assigning NULL to a variable (not pointer)
<> wrote in message
news: 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.

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

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.

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.

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

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

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

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.