Click here to Skip to main content
Click here to Skip to main content

Useful macros for pointer verification

, 20 Oct 2002
Rate this:
Please Sign up or sign in to vote.
A few macros to validate pointers passed to functions.
<!-- Add the rest of your HTML here -->
Download source file (0.4 Kb)


Most know the useful macros provided by various libraries named ASSERT, VERIFY (and similar) which just validates the provided argument. If the validation evaluates to false then a debug notification is raised.

In many cases this is sufficient for simple verifications but validating pointers is not the strength of this methods. Look at this example:

void MyFunction(LPSOMESTRUCT pData)
  ASSERT(pData != NULL);
  // ... more code
When you pass a NULL pointer to this function it will correctly detect it, but what if you pass 0xcdcdcdcd ? Its not NULL and its most probably not a valid address either. ASSERT will not catch it and you application will throw an exception.

More Macros

Here is a more advanced solution required. One possible solution is the use of the functions provided by the Windows API: IsBadReadPtr(), IsBadWritePtr(), IsBadStringPtr(). These functions take a memory location and a size as arguments and verify that the calling process really has read and/or write access to the location. It might be that the memory at the location is only partially accessible from your process, or that the memory is read or write only. These functions also detect this situations.

I've wrapped this functions into handy macros which you can use similar to the ASSERT and VERIFY macros.

#ifdef _DEBUG

       { if(::IsBadWritePtr(a, sizeof(LPDWORD))) \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid write pointer\r\n"));}}
		{ if(::IsBadReadPtr(a, sizeof(LPDWORD)))\
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid read pointer\r\n"));}}

		{ if(::IsBadWritePtr(a, l)) \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid write area\r\n"));}}
#define VERIFY_ISREADDATA(a, l)\
		{ if(::IsBadReadPtr(a, l))  \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid read area\r\n"));}}

		{ if(::IsBadWritePtr(a, sizeof(LPDWORD))) \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid write pointer\r\n")); ASSERT(false);}}
		{ if(::IsBadReadPtr(a, sizeof(LPDWORD)))  \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid read pointer\r\n")); ASSERT(false);}}

		{ if(::IsBadWritePtr(a, l)) \
		{ ::OutputDebugString(_T("Parameter ") _T(#a) \
		_T(" is not a valid write area\r\n")); ASSERT(false);}}
#define ASSERT_ISREADDATA(a, l)		{ if(::IsBadReadPtr(a, l))  \
		{ ::OutputDebugString(_T("Parameter ") _T(#a)\
		_T(" is not a valid read area\r\n")); ASSERT(false);}}



#define VERIFY_ISREADDATA(a, l)	




Our sample from before can be changed to this:

void MyFunction(LPSOMESTRUCT pData)
  // ... more code
Now it will correctly assert when you pass the address 0xcdcdcdcd or any other location from which the function can not read at least sizeof(SOMESTRUCT) bytes and the debug output will show "Parameter pData is not a valid read area".

I have found this to be a valuable tool when you write functions which take in or out pointers. Many problems related to bad pointers can easily be cured by using these validation macros.


This is compatible with any Windows version without restriction. It can be used with any Visual C++ version and all eVC versions. Anyway, using the macros is your responsability Smile | :)


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

No Biography provided

Comments and Discussions

GeneralGuaranteed Multithreading Problems Pinmemberpg--az12-Jun-09 3:22 
GeneralThese IsBadxxx functions are dangerous! PinmemberAaronJRidout31-Oct-07 6:38 
GeneralRe: These IsBadxxx functions are dangerous! PinmemberAndreas Saurwein Franci Gonalves31-Oct-07 6:56 
GeneralRe: These IsBadxxx functions are dangerous! PinmemberBlake Miller2-May-08 6:29 
Generalevc support Pinmemberhillol sarker12-Oct-04 23:17 
GeneralRe: evc support PinsussLiby Baby6-Jul-05 19:17 
Generalnew -> delete -> valid pointer PinmemberThomas Knauth18-Nov-02 6:14 
GeneralRe: new -> delete -> valid pointer PinmemberAndreas Saurwein18-Nov-02 6:45 
GeneralRe: new -> delete -> valid pointer PinmemberPhilippe Lhoste2-Dec-02 5:56 
GeneralRe: new -> delete -> valid pointer PinmemberAndreas Saurwein2-Dec-02 13:04 
Generalsizeof(LPDWORD) PinmemberMartin Bach22-Oct-02 2:11 
GeneralRe: sizeof(LPDWORD) PinmemberAndreas Saurwein22-Oct-02 3:54 
GeneralRe: sizeof(LPDWORD) PinmemberMartin Bach22-Oct-02 5:47 
GeneralRe: sizeof(LPDWORD) PinmemberAndreas Saurwein22-Oct-02 7:14 
GeneralRe: sizeof(LPDWORD) PinmemberMartin Bach22-Oct-02 21:19 
GeneralRe: sizeof(LPDWORD) PinsussAnonymous24-Oct-02 5:26 
GeneralRe: sizeof(LPDWORD) PinmemberAndreas Saurwein24-Oct-02 9:43 
GeneralRe: sizeof(LPDWORD) PinsussAnonymous24-Oct-02 14:01 
GeneralRe: sizeof(LPDWORD) PinmemberAndreas Saurwein25-Oct-02 3:19 
GeneralRe: sizeof(LPDWORD) PinsussAnonymous25-Oct-02 6:17 
GeneralRe: sizeof(LPDWORD) PinmemberAndreas Saurwein25-Oct-02 6:33 
GeneralRemove MFC dependency... PinmemberNguyen Binh21-Oct-02 17:47 
GeneralRe: Remove MFC dependency... PinmemberKarstenK21-Oct-02 21:42 
GeneralRe: Remove MFC dependency... PinmemberAndreas Saurwein21-Oct-02 23:55 
GeneralRe: Remove MFC dependency... PinmemberNguyen Binh22-Oct-02 2:37 
GeneralRe: Remove MFC dependency... PinmemberAndreas Saurwein22-Oct-02 4:00 
GeneralRe: Remove MFC dependency... PinmemberNguyen Binh23-Oct-02 1:02 
GeneralRe: Remove MFC dependency... PinmemberAndreas Saurwein23-Oct-02 1:52 
Basically you are right - it is pretty safe to use int 3 but why not doing it right from the beginning? Its a matter of habits. Once you learned to use it, it will make your and others (maintenance-) life much easier.
Its the same like using _T("whatever") instead of a simple "whatever". Next time the need arises to write something in unicode, you will be happy that you already write it correct automatically, instead of correcting dozens of compiler errors.
I'm not a language lawyer but I stick to proper use of the intended types.
I keep submitting “VB” as a Priority-1 bug, but apparently no one here knows how to fix it. Nick Hodapp, Semicolon

GeneralRe: Remove MFC dependency... PinmemberArmen Hakobyan21-Oct-02 23:54 
GeneralRe: Remove MFC dependency... Pinmember.:fl0yd:.14-Jun-03 14:33 
General0.4 kb PinsussAnonymous21-Oct-02 16:32 
GeneralRe: 0.4 kb PinmemberAndreas Saurwein21-Oct-02 23:56 
GeneralRe: 0.4 kb PinmemberNorm Almond22-Oct-02 1:06 
Generalverify vs trace PinmemberHugo Hallman21-Oct-02 6:55 
GeneralRe: verify vs trace PinmemberAndreas Saurwein21-Oct-02 7:10 
GeneralHelpfull PinmemberRoger Allen21-Oct-02 6:48 
GeneralTwo in one :) PinmemberArmen Hakobyan21-Oct-02 6:37 
GeneralRe: Two in one :) PinmemberAndreas Saurwein21-Oct-02 7:12 
GeneralRe: Two in one :) PinmemberRoger Allen23-Oct-02 3:38 
GeneralFormatting PinmemberGiles21-Oct-02 6:29 
GeneralRe: Formatting PinmemberAndreas Saurwein21-Oct-02 7:15 
GeneralRe: Formatting PinmemberGiles21-Oct-02 9:05 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150327.1 | Last Updated 21 Oct 2002
Article Copyright 2002 by Andreas S. Franci Gonçalves
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid