Announcement

Collapse
No announcement yet.

isbadreadptr isbadwriteptr etc

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • isbadreadptr isbadwriteptr etc

    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?

  • #2
    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.
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Originally posted by Michael Mattias View Post
      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.

      Comment


      • #4
        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
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


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

          Comment


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

            http://msdn.microsoft.com/en-us/libr...13(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.
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment

            Working...
            X