Any alternative for IsBadReadPtr / IsBadWritePtr
-
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
-
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
From where is this pointer coming from ?? In general, when playing with pointers, the thing you have to pay attention to is to initialize them to NULL. Then, you can simply check if the pointer is NULL or not using
if (pPointer)I don't see why you need to check for bad pointers...
Cédric Moonen Software developer
Charting control [v1.2] -
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
IsBadReadPtr / IsBadWritePtr are as good as it gets on Win32 I'm afraid. You shouldn't run into too much trouble as long as your app is doing 'ordinary' things with memory i.e. no mucking around with non-paged pool or using exception filters to allocate virtual memory. I wouldn't try using them against anything you expect to be allocated on the stack either as compiler optimisations might change behaviour between Debug and Release builds. That leaves you with IsBadReadPtr / IsBadWritePtr are fine for Heap memory you allocate yourself i.e. new and delete. I use a special class to check pointer parameters like this when they are passed. The template class has assignment from and cast to operators for the original pointer type. The cast calls the relevant check function whenever it is used. The checking classes are removed in the Release build for performance by the use of a macro. so
void SomeFunc( CNullPointerCheck pszData )which checks pszData for NULL on every call in Debug, becomesvoid SomeFunc( char* pszData )with zero overhead in Release builds. It gets written asvoid SomeFunc( _PC_NP(char*) pszData )which makes it clear this is a Parameter Check for Null Pointer Other classes check for Readable and Writable memory of a certain size at the target of the pointer using the IsBadReadPtr/IsBadWritePtr functions sovoid SomeFunc( _PC_WP(char*, 40) pszData )for example checks for at least 40 characters of writable memory. I'll post the whole lot as an article some day when I'm happy with the error reporting system.Nothing is exactly what it seems but everything with seems can be unpicked.
-
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
sw@thi wrote:
i need to check whether a pointer is valid or not...
Why?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
sw@thi wrote:
they also say that its not good practice to use these functions.
any particular reason!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixturecheers, Alok Gupta VC Forum Q&A :- I/IV Support CRY- Child Relief and You
-
sw@thi wrote:
i need to check whether a pointer is valid or not...
Why?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
IsBadReadPtr / IsBadWritePtr are as good as it gets on Win32 I'm afraid. You shouldn't run into too much trouble as long as your app is doing 'ordinary' things with memory i.e. no mucking around with non-paged pool or using exception filters to allocate virtual memory. I wouldn't try using them against anything you expect to be allocated on the stack either as compiler optimisations might change behaviour between Debug and Release builds. That leaves you with IsBadReadPtr / IsBadWritePtr are fine for Heap memory you allocate yourself i.e. new and delete. I use a special class to check pointer parameters like this when they are passed. The template class has assignment from and cast to operators for the original pointer type. The cast calls the relevant check function whenever it is used. The checking classes are removed in the Release build for performance by the use of a macro. so
void SomeFunc( CNullPointerCheck pszData )which checks pszData for NULL on every call in Debug, becomesvoid SomeFunc( char* pszData )with zero overhead in Release builds. It gets written asvoid SomeFunc( _PC_NP(char*) pszData )which makes it clear this is a Parameter Check for Null Pointer Other classes check for Readable and Writable memory of a certain size at the target of the pointer using the IsBadReadPtr/IsBadWritePtr functions sovoid SomeFunc( _PC_WP(char*, 40) pszData )for example checks for at least 40 characters of writable memory. I'll post the whole lot as an article some day when I'm happy with the error reporting system.Nothing is exactly what it seems but everything with seems can be unpicked.
-
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr. I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions. Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function?? Thanks for any help.
-
From where is this pointer coming from ?? In general, when playing with pointers, the thing you have to pay attention to is to initialize them to NULL. Then, you can simply check if the pointer is NULL or not using
if (pPointer)I don't see why you need to check for bad pointers...
Cédric Moonen Software developer
Charting control [v1.2]Thanks for your reply. here is why i think i need to check for bad ptr: theres this function in a class that would return a pointer. something like this CMyWnd *GetMyWnd(){ return m_myWnd}; now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this GetMyWnd()->SetSomeFunc(); // the application crashes here, in VS2005 where as in 2003 it works fine. this happens because the pointer that GetMyWnd returns is not a valid pointer and once it tries to acces any member of CMyWnd the application crashes. i've changed the above statement to something like this: CMyWnd *pWnd = GetMyWnd(); // i also tried CMyWnd *pWnd = NULL; pWnd = GetMyWnd(); if(pWnd) { pWnd->SetSomeFunc(); } to see what GetMyWnd returns. It returns a Junk value, and the if condition is evaluated to true and it enters inside and crashes. this is the reason that i thought i should check for NULL as well as Bad Ptr. how do i solve this?? is there anyother way??
-
IsBadReadPtr / IsBadWritePtr are as good as it gets on Win32 I'm afraid. You shouldn't run into too much trouble as long as your app is doing 'ordinary' things with memory i.e. no mucking around with non-paged pool or using exception filters to allocate virtual memory. I wouldn't try using them against anything you expect to be allocated on the stack either as compiler optimisations might change behaviour between Debug and Release builds. That leaves you with IsBadReadPtr / IsBadWritePtr are fine for Heap memory you allocate yourself i.e. new and delete. I use a special class to check pointer parameters like this when they are passed. The template class has assignment from and cast to operators for the original pointer type. The cast calls the relevant check function whenever it is used. The checking classes are removed in the Release build for performance by the use of a macro. so
void SomeFunc( CNullPointerCheck pszData )which checks pszData for NULL on every call in Debug, becomesvoid SomeFunc( char* pszData )with zero overhead in Release builds. It gets written asvoid SomeFunc( _PC_NP(char*) pszData )which makes it clear this is a Parameter Check for Null Pointer Other classes check for Readable and Writable memory of a certain size at the target of the pointer using the IsBadReadPtr/IsBadWritePtr functions sovoid SomeFunc( _PC_WP(char*, 40) pszData )for example checks for at least 40 characters of writable memory. I'll post the whole lot as an article some day when I'm happy with the error reporting system.Nothing is exactly what it seems but everything with seems can be unpicked.
I'll look forward to that article. We are not doing anything special with that ptr. just check for that pointer and then if its valid then call one more member from that ptr. i gave a full explanation in reply to cedric moonen's message above yours. Thanks for your reply.
-
Very interesting. It would seems that you should only use IsBad*Ptr if you can gaurentee 2 things. 1 You're not intentionally passing in exotic memory types like guard page addresses. 2 If anything goes wrong the app will stop because the result of the call will always be acted on. If you're writing the Win32 API you can't make these gaurentees so you shouldn't use the functions. In my case I use them in a framework where I can gaurentee both things so I feel reasonably justified in making this limited use.:)
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Thanks for your reply. here is why i think i need to check for bad ptr: theres this function in a class that would return a pointer. something like this CMyWnd *GetMyWnd(){ return m_myWnd}; now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this GetMyWnd()->SetSomeFunc(); // the application crashes here, in VS2005 where as in 2003 it works fine. this happens because the pointer that GetMyWnd returns is not a valid pointer and once it tries to acces any member of CMyWnd the application crashes. i've changed the above statement to something like this: CMyWnd *pWnd = GetMyWnd(); // i also tried CMyWnd *pWnd = NULL; pWnd = GetMyWnd(); if(pWnd) { pWnd->SetSomeFunc(); } to see what GetMyWnd returns. It returns a Junk value, and the if condition is evaluated to true and it enters inside and crashes. this is the reason that i thought i should check for NULL as well as Bad Ptr. how do i solve this?? is there anyother way??
sw@thi wrote:
now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this
You know what your real problem is - you say so. Fix the real problem instead of trying to use a function to cover up the error. cdcdcdcd is a value that indicates an uninitialized variable. It appears that your GetMyWnd function is not maintaining the value of m_myWnd. Figure out why Judy
-
Very interesting. It would seems that you should only use IsBad*Ptr if you can gaurentee 2 things. 1 You're not intentionally passing in exotic memory types like guard page addresses. 2 If anything goes wrong the app will stop because the result of the call will always be acted on. If you're writing the Win32 API you can't make these gaurentees so you shouldn't use the functions. In my case I use them in a framework where I can gaurentee both things so I feel reasonably justified in making this limited use.:)
Nothing is exactly what it seems but everything with seems can be unpicked.
I’ve actually fallen victim to a stack guard-page corruption caused by the numerous calls to
IsBadReadPtrandIsBadWritePtrin MFC. It wasn’t at all obvious that the memory page in question was on the stack and not the heap (it took ages to even discover that the guard page on the stack was corrupted); after all every local variable is on the stack and many such variables are passed “through” MFC. It took many weeks to debug the issue. Anyway, what’s the point of a function succeeding if it’s called with some random pointer and thus can’t access the data it needs to do its job? Don’t validate memory, crash! Then the source of the problem is staring you in the face instead of some problem far removed from the actual source.Steve