Sebastian Lackner sebastian@fds-team.de writes:
Even if native would behave differently, and we probably would decide not to reproduce the behaviour - the tests are a good documentation of how it is supposed to work. The next person who wants to know if WideCharToMultibyte(CP_UTF7, ...) changes the error code, will have to write those tests just again.
Any good reason behind this?
With a few exceptions, Windows doesn't alter last error on success, so its value depends more or less randomly on internal code paths, and on whether there was a failure in one of the subfunctions.
Since we don't replicate the internal code paths, the only way to pass the tests would be to explicitly set last error on success. Of course, as soon as we start doing that, we change the last error behavior of all the callers of that function, which then need to set last error too, or worse, save/restore it around subfunction calls.
Pretty soon we'll be setting last error in every single code path, for no benefit except passing a few misguided tests.