Archived

This topic is now archived and is closed to further replies.

SagaEterna

finding when a pointer is set to NULL

Recommended Posts

Hello, here''s my problem, i work with a high level abstraction engine. One member of a class is set to NULL by the engine, but i cannot trace the code to find when (because the high level of abstraction). Is there a way with visual c++ to find when the pointer is set to NULL? Thanks.

Share this post


Link to post
Share on other sites
Use a data breakpoint. First, find a function that sets the pointer in question to a non-NULL value. Put a normal breakpoint in that function using F9. Let the program run to that breakpoing. Then find out the address that that pointer points to. Try adding that pointer to the watch window, for example. Once you know the address that is overwritten with NULL, hit Alt-F9, and go to data. Enter (int *) 0x12345678, replacing 0x12345678 with the actual address. Hit F5, and when someone sets the value of that pointer to NULL you should be broken on the according line.

---
Come to #directxdev IRC channel on AfterNET

Share this post


Link to post
Share on other sites
quote:
Original post by Mr Sam
if (!ptr)
{

}

Even neater



I dear to disagree. This kind of syntax is IMO okay when dealing with numerical values, such as integers, to check if the value of the int is zero. Currently we''re dealing with a totally different concept, pointers. Pointers never have a zero value, they either point to something, or not. I agree, it is legal to write if(!ptr), but I would personally discourage you from mixing up real data members and pointers at this point (no pun inteded ) - if your pointer points to nothing, it is a NULL-pointer, it does not have the value zero! Hence, in case of pointers, it would be clearer to write if(ptr == NULL), especially since there is no 100% guarantee that NULL == 0.

Crispy

Share this post


Link to post
Share on other sites
quote:
Original post by Crispy
I dear to disagree. ... Hence, in case of pointers, it would be clearer to write if(ptr == NULL), especially since there is no 100% guarantee that NULL == 0.



Even ignoring the fact that NULL is guaranteed to be 0, this way of testing the pointer value leaves you vulnerable to a particularly nasty typo bug which can cause horrible problems in your code:


if(ptr = NULL)
{
// error handling code
}


This is nasty because it mucks up your pointer, but the error handling code never gets called. So your program will crash horribly for no apparent reason. In fact, it wouldn't surprise me if something like this was causing the problem the original poster is complaining about - it is an easy mistake to make, and it can be a right bastard to spot.

It is safer to reverse the expression, e.g:


if(NULL == ptr)
{
}


This way, if you accidentally use = instead of ==, the compiler will complain.

[edit] to answer the original question:

Use the debugger to set a watch on the variable to see where it gets set to NULL. You can also try looking at the stack dump to see which functions are being called leading up to the error, to help narrow it down.




[edited by - Sandman on July 15, 2002 7:38:33 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Sandman

Even ignoring the fact that NULL is guaranteed to be 0, this way of testing the pointer value leaves you vulnerable to a particularly nasty typo bug which can cause horrible problems in your code:


if(ptr = NULL)
{
// error handling code
}


This is nasty because it mucks up your pointer, but the error handling code never gets called. So your program will crash horribly for no apparent reason. In fact, it wouldn't surprise me if something like this was causing the problem the original poster is complaining about - it is an easy mistake to make, and it can be a right bastard to spot.

It is safer to reverse the expression, e.g:


if(NULL == ptr)
{
}


This way, if you accidentally use = instead of ==, the compiler will complain.



good idea.. but I stand by just don't make that damn mistake..
I never make typo's... EVER

EDIT: oh dear.. this server STILL doesn't support double quoting


[edited by - jamie7 on July 15, 2002 7:32:37 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by FearedPixel
lol, i guess you learn new things every day

tomorrow i might be told that a byte isn''t actually 8 bits..


Foldoc sez:
quote:
A byte may be 9 bits on 36-bit computers. Some older architectures used "byte" for quantities of 6 or 7 bits, and the PDP-10 and IBM 7030 supported "bytes" that were actually bit-fields of 1 to 36 (or 64) bits! These usages are now obsolete, and even 9-bit bytes have become rare in the general trend toward power-of-2 word sizes.

Share this post


Link to post
Share on other sites
quote:
Original post by Crispy
I dear to disagree. This kind of syntax is IMO okay when dealing with numerical values, such as integers, to check if the value of the int is zero. Currently we''re dealing with a totally different concept, pointers. Pointers never have a zero value, they either point to something, or not. I agree, it is legal to write if(!ptr), but I would personally discourage you from mixing up real data members and pointers at this point (no pun inteded ) - if your pointer points to nothing, it is a NULL-pointer, it does not have the value zero! Hence, in case of pointers, it would be clearer to write if(ptr == NULL), especially since there is no 100% guarantee that NULL == 0.


Except Stroustrup states in the C++ standard that you should never use NULL, you should always set your pointers to 0.

---
Make it work.
Make it fast.

"Commmmpuuuuterrrr.." --Scotty Star Trek IV:The Voyage Home

Share this post


Link to post
Share on other sites
quote:
Original post by CaptainJester
Except Stroustrup states in the C++ standard that you should never use NULL, you should always set your pointers to 0.

To be precise, he explains in his book The C++ Programming Language why he prefers 0 to NULL. There''s no mention of this issue in the Standard and, if there was, there would be no indication that Stroustrup had written it. In terms of the Standard, both are correct.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Sandman
[quote]Original post by Crispy
I dear to disagree. ... Hence, in case of pointers, it would be clearer to write if(ptr == NULL), especially since there is no 100% guarantee that NULL == 0.



Even ignoring the fact that NULL is guaranteed to be 0, this way of testing the pointer value leaves you vulnerable to a particularly nasty typo bug which can cause horrible problems in your code:


if(ptr = NULL)
{
// error handling code
}


This is nasty because it mucks up your pointer, but the error handling code never gets called. So your program will crash horribly for no apparent reason. In fact, it wouldn''t surprise me if something like this was causing the problem the original poster is complaining about - it is an easy mistake to make, and it can be a right bastard to spot.

It is safer to reverse the expression, e.g:


if(NULL == ptr)
{
}


This way, if you accidentally use = instead of ==, the compiler will complain.

[edit] to answer the original question:

Use the debugger to set a watch on the variable to see where it gets set to NULL. You can also try looking at the stack dump to see which functions are being called leading up to the error, to help narrow it down.




<SPAN CLASS=editedby>[edited by - Sandman on July 15, 2002 7:38:33 AM]</SPAN>

Amazingly enough, this little nugget above was the first thing I learnt when I started work after finishing college (other programmers were doing it and I had to ask why!).



Share this post


Link to post
Share on other sites
quote:
Original post by FearedPixel
lol, i guess you learn new things every day

tomorrow i might be told that a byte isn''t actually 8 bits..


It actually isn''t!!! A byte is defined as the smallest addressable memory on a machine. It just happens that pretty much all the CPU have an Octet( which is the correct word for 8 bits data and is, to confuse the story even more, the french equivalent of byte!) has their smallest addressable data.

But It is probably safe to say that to support backward compatibility all machines will always support an 8 bits datatype. And so the distinction will problably never matter.

Share this post


Link to post
Share on other sites

-=Off Topic=-

*sigh*

NULL is left over from older versions of C and is completely unnecessary in modern C++ code. It exists solely to provide backwards compatibility with legacy code.

p==NULL is fine if you make sure to include cstddef or one of the other C standard library headers that are guaranteed to define NULL before you use it. Otherwise, you are unnecessarily relying on a nonstandard extension, which is a no-no. p==0 is always standard.

However, both of the previously mentioned methods of testing for null pointers are redundant. !p is the best way of doing it because it requires less typing and has been defined to mean the same thing as p==0. And plain old p means p!=0 in logical expressions.

The following C++ code is both correct and concise.


  # include <iostream>

using namespace std;

int main ()
{
cout << "assigning zero to p..." << endl;

int* p=0;

if ( p) cout << "p!=0";
if (!p) cout << "p==0";

cout << endl << "assigning non-zero value to p..." << endl;

p = new int [5];

if ( p) cout << "p!=0";
if (!p) cout << "p==0";

cout << endl << "assigning zero to p..." << endl;

delete [] p; p = 0;

if ( p) cout << "p!=0";
if (!p) cout << "p==0";

cout << endl;
}


Output:
assigning zero to p...
p==0
assigning non-zero value to p...
p!=0
assigning zero to p...
p==0

Share this post


Link to post
Share on other sites
quote:
Original post by null_pointer
p==NULL is fine if you make sure to include cstddef or one of the other C standard library headers that are guaranteed to define NULL before you use it. Otherwise, you are unnecessarily relying on a nonstandard extension, which is a no-no.

What are you saying is a non-standard extension?

Share this post


Link to post
Share on other sites
See previous post. Er...just kidding.

NULL is only defined in certain header files included in C++ for backwards compatibility with C. The C++ header files that are guaranteed by the standard to define NULL are: clocale, cstddef, cstdio, cstdlib, cstring, ctime, cwchar. If you do not make certain that those files are somehow included before you use NULL, you are relying on NULL to be defined somewhere else not guaranteed by the standard. Therefore, you would be relying on a nonstandard extension.

This header file is very poor style:


  
# ifndef SOMECLASS
# define SOMECLASS

class someclass
{
int* p;

public:
someclass () : p (NULL) {}

// ...

};

# endif


And this is a more insidious example:


  
# include <iostream>

using namespace std;

int main ()
{
int* p = NULL;

if ( p) cout << "p!=0";
if (!p) cout << "p==0";

cout << endl;
}


In that example, NULL may or may not be defined depending on whether iostream includes one of the seven headers mentioned above that are guaranteed to define NULL. But here is the problem: iostream isn''t guaranteed by the standard to include any other headers. In fact, none of the C++ standard library headers is guaranteed to include any of the other headers.

Use zero instead of NULL.

Share this post


Link to post
Share on other sites
quote:
Original post by null_pointer
And this is a more insidious example:


Bah. If NULL isn''t defined yet, the compiler will complain so it''s no big deal. Unless someone is stupid enough to write
//MUHAHAHAHA (stupid people like that MUAHAHA)
#define NULL 1

Could anyone tell me why Stroustrup prefers 0 over NULL?

Cédric

Share this post


Link to post
Share on other sites
Just to state this, NULL isn''t 0. Null is used to dereference pointers and it looks something like (void*)0. I don''t think it matters in c++ but c programmmers might have problems setting it to 0 instead of setting it to a pointer that doesn''t point anywhere.

---
My Site
Come join us on IRC in #directxdev @ irc.afternet.org

Share this post


Link to post
Share on other sites