Re: [PATCH 1/3] lz32/tests: Test more last errors set by LZOpenFile[AW].
"Saulius Krasuckas" <saulius.krasuckas(a)ieee.org> wrote:
memset(&filled_0xA5, 0xA5, OFS_MAXPATHNAME); memset(&test, 0xA5, sizeof(test)); full_file_path_name_in_a_CWD(filename_, expected, FALSE); + SetLastError(0xfaceabee);
Please use a usual value we all agreed to use: 0xdeadbeef. It makes sense to check last error value only if an API has failed, while you are adding last error checks everywhere. Unless you have an application that depends on it, that's wrong. -- Dmitry.
Hello, Dmitry, * On Wed, 27 Sep 2006, Dmitry Timoshkov wrote:
* "Saulius Krasuckas" <saulius.krasuckas(a)ieee.org> wrote:
memset(&filled_0xA5, 0xA5, OFS_MAXPATHNAME); memset(&test, 0xA5, sizeof(test)); full_file_path_name_in_a_CWD(filename_, expected, FALSE); + SetLastError(0xfaceabee);
Please use a usual value we all agreed to use: 0xdeadbeef.
I remember only countless proposals by you to agree on it, but no any documented place marking such agreement. If that's of such an important matter, why still no one has added some janitorial page about it? (in the wiki for example)
It makes sense to check last error value only if an API has failed, while you are adding last error checks everywhere. Unless you have an application that depends on it, that's wrong.
Well, thanks. I'll change that, but is it wrong just because it slightly increases code complexity for no direct benefit? I just want to know for future.
On Di, 2006-10-03 at 20:40 +0300, Saulius Krasuckas wrote:
It makes sense to check last error value only if an API has failed, while you are adding last error checks everywhere. Unless you have an application that depends on it, that's wrong.
Well, thanks. I'll change that, but is it wrong just because it slightly increases code complexity for no direct benefit? I just want to know for future.
For the normal case, SetLastError() is called only on failure. http://msdn.microsoft.com/library/en-us/debug/base/setlasterror.asp There might be some broken Applications, that expect GetLastError() to return a special Value, even when a Function returns success, but they will fail very fast on native Windows with a different version of Windows, SP, Hotfix or Driver. Do you have such a Application? -- By by ... Detlef
* On Tue, 3 Oct 2006, Detlef Riekenberg wrote:
* On Di, 2006-10-03 at 20:40 +0300, Saulius Krasuckas wrote:
Well, thanks. I'll change that, but is it wrong just because it slightly increases code complexity for no direct benefit? I just want to know for future.
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? :)
There might be some broken Applications, that expect GetLastError() to return a special Value, even when a Function returns success, but they will fail very fast on native Windows with a different version of Windows, SP, Hotfix or Driver.
That could be a way for a program to differentiate between 9x and NT versions without calling GetVersion*(). I saw one code/app in the past, which did such check by querying kernel32.dll for the OpenVxD export ;)
Do you have such a Application?
No, I didn't. If I had, that would be my primary argument. I even doubt there exist any application that calls LZOpenFileW() in the world, but still Wine implements it plus it contains W-to-A cross-call, by eliminating which 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 ;) But nevermind, Detlef. I will add those "wrong" checks just in some of my internal branches to make my fantasyless life easier and won't disturb the life of the whole project :]
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) -- By by ... Detlef
participants (3)
-
Detlef Riekenberg -
Dmitry Timoshkov -
Saulius Krasuckas