Sign in to follow this  
ehmdjii

when are pointers true or false

Recommended Posts

ehmdjii    238
int * i;

if (i)
{
//true
}

can a pointer be evaluated to true or false? when is it true and when is it false? what if it hasn't been assigned, like in the example? what if it has? what about the NULL - pointer? thanks1

Share this post


Link to post
Share on other sites
BauerGL    467
A pointer is 'false' if it is NULL (0), otherwise it is 'true'. But you should never use uninitialized pointers since they'll automatically point to a random location in memory. Messing with random memory is a bad idea and usually ends in a crash.

So remember to always initialize your pointers (to 0 if nothing else)!

Share this post


Link to post
Share on other sites
Fruny    1658
Values interpreted in a boolean context are true when non-zero and false when zero. NULL is just a preprocessor macro that evaluates to zero. Thus a 'NULL' pointer will be false, and any other pointer will be true.

Share this post


Link to post
Share on other sites
Enigma    1410
Quote:
C++ Standard (Final Draft), Section 4.12, Paragraph 1
An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

Enigma

Share this post


Link to post
Share on other sites
ehmdjii    238
thank you all!

so when i leave the pointer uninitialized like in the above example, it will still evaluate to true, cause it points to random memory?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by Fruny
Values interpreted in a boolean context are true when non-zero and false when zero. NULL is just a preprocessor macro that evaluates to zero. Thus a 'NULL' pointer will be false, and any other pointer will be true.

AP

Share this post


Link to post
Share on other sites
Kitt3n    468
The chance that some random garbage is in memory is higher
than that you accidentally hit a memory location with '0'/false..

So it will be true with high probability.

But like the other posters said, having uninitialized pointers
and doing sth with them is just asking for problems.

Share this post


Link to post
Share on other sites
Marmin    523
if you set a pointer to Null it points to nothing.
So if you have set (pseudocode)

pointer1 = Null

if pointer1 = Null then Dosomething
then it will execute Dosmething.
You cannot set pointer to boolean values.

Share this post


Link to post
Share on other sites
Extrarius    1412
Quote:
Original post by Fruny
Values interpreted in a boolean context are true when non-zero and false when zero. NULL is just a preprocessor macro that evaluates to zero. Thus a 'NULL' pointer will be false, and any other pointer will be true.
As far as I can tell, according to A working paper containing the Current ISO C standard incl TC1 and TC2[PDF] (on JTC1/SC22/WG14 - C), your last two statements aren't neccessarily true if the language in question is C (and the same likely applies to C++, but I haven't checked). I don't see any specification that indicates a 'null pointer constant' stored in a pointer will convert back to 0. It is specified that an "integer constant expression with the value 0" is a 'null pointer constant', but it seems that once it is converted to a pointer type, there is no guarantee that it can be converted back to the same value. Unless I'm missing something, conversion between pointers and integers is allowed, but the behavior is implementation-defined.

Of course, that paper isn't the actual current standard, but I think it is mostly the same, and what differences exist are things being considered for the next standard since.

Also, the behavior you describe is true on every system I've worked on or heard of, but it doesn't seem to be covered by the C standard. I doubt that C++ specifies the behavior either, because if it did and it was an actual 'hole' in the C standard it seems likely somebody would have noticed the difference and fixed it.

Share this post


Link to post
Share on other sites
Nathan Baum    1027
Quote:
Original post by Extrarius
Quote:
Original post by Fruny
Values interpreted in a boolean context are true when non-zero and false when zero. NULL is just a preprocessor macro that evaluates to zero. Thus a 'NULL' pointer will be false, and any other pointer will be true.
As far as I can tell, according to A working paper containing the Current ISO C standard incl TC1 and TC2[PDF] (on JTC1/SC22/WG14 - C), your last two statements aren't neccessarily true if the language in question is C (and the same likely applies to C++, but I haven't checked). I don't see any specification that indicates a 'null pointer constant' stored in a pointer will convert back to 0.

I don't think this matters. [smile]

The standard specifies that "if (x) y" will execute y if "x compares equal to 0".

The rules for equality state that "if one operand is a null pointer constant, it is converted to the type of the other operand". Whilst x might not be a null pointer constant, 0 is. Hence, 0 is converted to a null pointer of the same type as x, and comparison proceeds as usual for pointer types.
Quote:

It is specified that an "integer constant expression with the value 0" is a 'null pointer constant', but it seems that once it is converted to a pointer type, there is no guarantee that it can be converted back to the same value. Unless I'm missing something, conversion between pointers and integers is allowed, but the behavior is implementation-defined.

Of course, that paper isn't the actual current standard, but I think it is mostly the same, and what differences exist are things being considered for the next standard since.

Also, the behavior you describe is true on every system I've worked on or heard of, but it doesn't seem to be covered by the C standard. I doubt that C++ specifies the behavior either, because if it did and it was an actual 'hole' in the C standard it seems likely somebody would have noticed the difference and fixed it.

C++ converts the result of boolean expressions to "bool" type before testing them. The conversion from pointer to Boolean is fully defined. So there's no problem in C++.

Share this post


Link to post
Share on other sites
Extrarius    1412
Nathan Baum: Of course. I'm not sure why I didn't think to look up 'if'. Still, IMO it is interesting that "if((int)Pointer){}"(or even "if((intptr_t)Pointer){}") is apparently implementation dependent, while "if(Pointer){}" is not.

Share this post


Link to post
Share on other sites
foreignkid    142
IIRC, NULL is not guaranteed to be zero on all systems. However, it is guaranteed to always be false, and consequently all compiler writers in their right minds have made NULL = 0.

Share this post


Link to post
Share on other sites
Zahlman    1682
I prefer to see if(pointer) because it is idiomatic:


Data* data = NULL;
// ...
// sekret codes! will the pointer be assigned or not? :o
// ...
if (data) { // "if we have data"
data.doSomething();
}


But it's also nicer to avoid nulls where possible, especially via the use of a Null Object pattern where it makes sense - because extra if's are icky in their own way too.

Share this post


Link to post
Share on other sites
me22    212
In C++ one is generally suggested to just use 0 anyways, since C headers like to set NULL to ((void*)0), which doesn't work properly in C++ ( because there's no implicit conversion to T* from void*).

...at least until the nullptr proposal gets accepted ;)

Share this post


Link to post
Share on other sites
WillC    548
Quote:
Original post by ehmdjii
thank you all!

so when i leave the pointer uninitialized like in the above example, it will still evaluate to true, cause it points to random memory?




No, it will randomly be either true or false. Although the random value needs to be 0 for it to evaluate to false, it is very common for this to happen with variables allocated on the stack. Always initialise your variables, unless you have a very good reason not to.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by Zahlman

Data* data = NULL;
...
if (data) { // "if we have data"
data.doSomething();



There should be a "->" instead of a "." since it's a pointer.

Share this post


Link to post
Share on other sites
Nathan Baum    1027
Quote:
Original post by Extrarius
Nathan Baum: Of course. I'm not sure why I didn't think to look up 'if'. Still, IMO it is interesting that "if((int)Pointer){}"(or even "if((intptr_t)Pointer){}") is apparently implementation dependent, while "if(Pointer){}" is not.

Well, it's because C and C++ are engaging in a bit of doublethink with regards to '0'.

0 is both an integer constant, and the null pointer constant. C++ sensibly doesn't define conditional expressions in terms of comparison to 0, but neither language is prepared to have distinct syntax for a null pointer constant.

Additionally, there's no rule that says the null pointer has to point at the first byte of memory. The null pointer might point at some other location. It only needs to be distinct from any other pointer. If you're allowed to have a non-null pointer which points at the first byte, then obviously the null pointer can't point there.

On Intel architectures at least, location zero is a real memory location and contains the start of the interrupt table, which you'd have to be able to access if you were writing a kernel, say.

Of course, for efficiency reasons it's better to use a zero, since comparisons to it can be done very quickly on most architectures. You'd probably use assembly for access the interrupt table, where you'd just have to know whether a 0 was a null pointer or a pointer to the first byte of memory.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this