On Mi, 2006-10-04 at 23:22 +0300, Saulius Krasuckas wrote:
For the normal case, SetLastError() is called only on failure. http://msdn.microsoft.com/library/en-us/debug/base/setlasterror.asp
Do we trust MSDN when we can check things ourselves? No, we don't trust, right? :)
We trust MSDN, as log as we detect, that something is missing or wrong.
I want to ensure no algorithmic logic was flawed in A-version or in W-version of mentioned function. Hence my intense testing for SetLastError(). I hoped this would let me easier to (re)build code for LZOpenFile[AW]. It would make the code stricter. So I won't be lost in some lots of possible solutions ;)
It's ok for learning and internal tests, but Alexandre teached me, not to put everything in the testsuite. He specially mentioned to avoid testing GetLastError() on success, unless an Application need this behavior.
An current Example from "localspl.dll" => pfnEnumPorts: With the native dlls (w2k+xp) on wine, GetLastError() return always 10047 on Success.
The Reason was easy to find after the message from wine: fixme:winsock:convert_af_w2u unhandled Windows address family 26
Our ws2_32.dll does not Support WS_AF_IRDA (26) => AF_IRDA (23 on linux)