isbadreadptr isbadwriteptr etc

[Michael Mattias]

My SDK-on-disk does not have the 'obsolete' disclaimer, so I looked at MSDN"

http://msdn.microsoft.com/en-us/library/aa366713(VS.85).aspx

The 'obsolete' disclaimer is qualified by "see remarks" so I read those, too.

All such disclaimers seem to this observer related to sloppy thread management; however, the "tag" added as communtity content seems to describe a reason to avoid these fuctions.

[Chris Holbrook]

...and it doesn't help with the second case either, so I think the advice stands - don't use it.

[Michael Mattias]

but if you are using a 3rd party library, you won't even know whether you have a problem.

If the price of said library was too good to be true it probably was.

However, this is generally going to a problem for the library USER (that would be you)... to ensure you are not calling a library function from your program when a thread switch could conceivably invalidate a passed address.

MCM

[Chris Holbrook]

This is the purpose for which synchronization objects exist.

Assuming that have control of the whole development, but if you are using a 3rd party library, you won't even know whether you have a problem.

[Michael Mattias]

From Mr Osterman's comments:

There’s nothing to prevent another thread in the application from unmapping the virtual address passed into IsBadReadPtr immediately after the call is made. Which means that any error checks you made based on the results of this API aren’t valid (this is called out in the documentation for IsBadWritePtr/IsBadReadPtr).

This is the purpose for which synchronization objects exist.

If you are creating multi-threaded applications, the CRITICAL_SECTION would be the object of choice.

[Chris Holbrook]

If you were thinking about using the above API functions, you would do well to read first the MSDN (not WIN32.HLP) entry for isbadreadptr taking particular note of the "user content" - also http://blogs.msdn.com/larryosterman/...18/134471.aspx. The way I read these sources is "DON'T!".

It is not as simple as "oh, my application is a single thread, so no problem"!

Not for nothing have these functions been described as

“CrashMyApplication” and “CorruptMemoryAndCrashMySystem"

Not for nothing does MSDN say

"Important This function is obsolete and should not be used. Despite its name, it does not guarantee that the pointer is valid or that the memory pointed to is safe to use."

don't take the Win32 Programmers Reference word for it!!*

Actually I haven't checked that my WIn32Programmer Reference is bang up to date on these functions - anyone?