On Sun, 2004-06-06 at 19:26, Robert Reif wrote:
Not a real program but Microsoft's API checking programs do try non NULL bad pointers and expect an error return rather than a program crash.
Are you saying checking a good pointer can cause problems?
No, checking a bad pointer can cause problems. See: http://blogs.msdn.com/LarryOsterman/archive/2004/05/18/134471.aspx
Rob
Robert Shearman wrote:
On Sun, 2004-06-06 at 19:26, Robert Reif wrote:
Not a real program but Microsoft's API checking programs do try non NULL bad pointers and expect an error return rather than a program crash.
Are you saying checking a good pointer can cause problems?
No, checking a bad pointer can cause problems. See: http://blogs.msdn.com/LarryOsterman/archive/2004/05/18/134471.aspx
Rob
Interesting read. I would have thought Microsoft would have checked if the memory range was already mapped and had the proper access permission rather than just accessing it and catching the page fault. The whole point of the check is to prevent a problem, not cause it. It's hard to believe that's what they are doing. Explains a lot though.
On Sun, 06 Jun 2004 16:15:43 -0400, Robert Reif wrote:
Interesting read. I would have thought Microsoft would have checked if the memory range was already mapped and had the proper access permission rather than just accessing it and catching the page fault. The whole point of the check is to prevent a problem, not cause it. It's hard to believe that's what they are doing. Explains a lot though.
Yeah. The bit about accidentally touching the guard page was scary, especially as that sort of mistake would be so easy to make and is so subtle. Once again I find myself cursing the ridiculous levels of fault tolerance in these APIs - if an application passes bogus pointers into something like GTK they either get a non-fatal assertion and the function returns, or the app crashes with a helpful backtrace to show you what you did wrong.
I expect these APIs were thrown into Win32 one afternoon by a bored (paranoid) programmer who was in the "we can't trust the user" school of thought, without much review or thinking through, and written in the easiest way possible. Then other teams began using them because they were there and hey, it's so easy, why not?
Mike Hearn wrote:
On Sun, 06 Jun 2004 16:15:43 -0400, Robert Reif wrote:
Interesting read. I would have thought Microsoft would have checked if the memory range was already mapped and had the proper access permission rather than just accessing it and catching the page fault. The whole point of the check is to prevent a problem, not cause it. It's hard to believe that's what they are doing. Explains a lot though.
Yeah. The bit about accidentally touching the guard page was scary, especially as that sort of mistake would be so easy to make and is so subtle. Once again I find myself cursing the ridiculous levels of fault tolerance in these APIs - if an application passes bogus pointers into something like GTK they either get a non-fatal assertion and the function returns, or the app crashes with a helpful backtrace to show you what you did wrong.
I expect these APIs were thrown into Win32 one afternoon by a bored (paranoid) programmer who was in the "we can't trust the user" school of thought, without much review or thinking through, and written in the easiest way possible. Then other teams began using them because they were there and hey, it's so easy, why not?
I can see the evils of using IsBadWritePtr now but it seems that Microsoft does use it in their winmm implementation and to be compatible, wine probably should too. I think the patch is valid.
I can see the evils of using IsBadWritePtr now but it seems that Microsoft does use it in their winmm implementation and to be compatible, wine probably should too. I think the patch is valid.
I'd rather think unless we find an app which absolutely requires it, we'd better leave it as it is (and don't make use of IsBadReadPtr).
A+
-
Eric Pouech -
Mike Hearn -
Robert Reif -
Robert Shearman