Holy cow, I wrote a book!
IsBadXxxPtr is a bad idea and you shouldn't call it.
In the comments, many people proposed changes to the function to
improve the implementation.
But what's the point?
IsBadXxxPtr is just a bad idea.
There's no point improving the implementation of a bad idea.
On the other hand, some people suggested making it clear that
IsBadXxxPtr is a bad idea by making it worse.
While this is tempting in a "I'm forcing you to do the right thing"
sense, it carries with it serious compatibility problems.
There's a lot of code that uses IsBadXxxPtr even though
it's a bad idea, and making IsBadXxxPtr worse would
risk breaking those programs that managed to get away with it up
The danger of this is that people would upgrade to the next version
of Windows and their program would stop working.
Who do you think the blame will be placed on?
Sure, you might tell these people,
"That's because it's a bug in your program.
Go contact the vendor for an update."
Of course, that's assuming you can prove that the reason why
the program stopped working was this IsBadXxxPtr stuff.
How can you tell that that was the problem?
Maybe it was caused by some other problem,
possibly even a bug in Windows itself.
Or is your answer just going to be "Any program that crashes
must be crashing due to misuse of IsBadXxxPtr?"
And, as I've noted before, contacting the vendor may not be enough.
Most large corporations have programs that run their day-to-day
Some of them may have been written by a consultant ten years ago.
Even if they have the source code, they may not have the expertise,
resources, or simply inclination go to in and fix it.
This happens more often than you think.
To these customers, the behavior change is simply a regression.
Even if you have the source code and expertise, fixing the problem
may not be as simple as it looks.
You may have designed your program poorly and relied on
IsBadXxxPtr to cover for your failings.
For example, you may have decided that
"The lParam to this message is a pointer to
a CUSTOMER structure, or it could just be
the customer ID number.
I'll use IsBadReadPtr, and if the pointer is bad,
then the value must be the customer ID number."
may have changed the definition of a function parameter
and now need to detect whether your caller is calling the "old function"
or the "new one".
Or it could simply be that once you remove the call to
IsBadXxxPtr, your program crashes constantly
because the IsBadXxxPtr was covering up for
a huge number of other programming errors (such as uninitialized
"But what if I'm just using it for debugging purposes?"
For debugging purposes, allow me to propose the following
drop-in replacement functions:
inline BOOL IsBadReadPtr2(CONST VOID *p, UINT_PTR cb)
memcmp(p, p, cb);
inline BOOL IsBadWritePtr2(LPVOID p, UINT_PTR cb)
memmove(p, p, cb);
It's very simple: To see if a pointer is bad for reading,
just read it (and similarly writing).
If the pointer is bad, the read (or write) will raise an exception,
and then you can investigate the bad pointer at the point it
We read from the memory by comparing it to itself
and write to the memory by copying it to itself.
These have no effect but they do force the memory to be
read or written.
Of course, this trick assumes that the compiler didn't optimize
out the otherwise pointless "compare memory to itself"
and "copy memory to itself" operations.
(Note also that the replacement IsBadWritePtr2
is not thread-safe, since another thread might be modifying the
memory while we're copying it.
But then again, the original IsBadWritePtr wasn't
thread-safe either, so there's no loss of amenity there.)
(As an aside: I've seen people try to write replacements
for IsBadXxxPtr and end up introducing a bug along
There are many corner cases in this seemingly-simple family of