On 8/13/21 3:46 PM, Hugh McMaster wrote:
I'm adding tests for SetCurrentConsoleFontEx to dlls/kernel32/tests/console.c.
The behaviour is unusual on Windows and changes on 32-bit and 64-bit systems.
For example, when deliberately testing failure, the 32-bit function returns ERROR_INVALID_HANDLE, while the 64-bit equivalent returns ERROR_INVALID_PARAMETER.
In one particular test, the 32-bit function even returns non-zero (success), while the 64-bit function correctly returns zero (failure).
Should I mark the the 32-bit return codes as broken?
And what should I do about the zero/non-zero difference? Writing something like ok(!ret || broken(ret), ...) seems rather strange.
I'm also wondering how to manage this when implementing the function.
When there is such difference, applications most likely don't depend on this behaviour, so you may probably just pick the one that makes more sense to you. It also means that it's not really important to have strict tests.
If one of behaviours is clearly broken, we may have it marked with something like broken(ret && sizeof(void *) == 4) so that the test is still strict on 64-bit systems (or the other way around). But if it's not clear that it's really broken, then dropping the test may be a better choice.
Thanks,
Jacek