On Mon, 21 Apr 2008, Robert Reif wrote:
That's the whole point of the test, to check what happens with an invalid argument.
So what do you think *should* happen with an invalid argument? The result is different on different Windows platforms. The behaviour is not specified by MSDN.
In any case, continuing and executing code that uses "capsA" even though the waveOutGetDevCapsA call failed is definitely wrong.
This is the proper fix:
The fix for this part of the problem is fine. Please apply.
However, I still think it's VERY strange to expect success from an invalid call. You are describing it as an "invalid argument" yourself. Why should we expect a call with an "invalid argument" to succeed? And again, the test does NOT pass on all Microsoft versions; it fails on Terminal Servers.
If the point is to verify that waveOutGetDevCaps doesn't write more than the size supplied, this should be verified. I'd also like to point out that the Wine implementation also doesn't handle this correctly: Only waveOutGetDevCapsA does a memcpy() using the size argument; waveOutGetDevCapsW does not.
Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
diff --git a/dlls/winmm/tests/wave.c b/dlls/winmm/tests/wave.c index 60f0622..37367c2 100644 --- a/dlls/winmm/tests/wave.c +++ b/dlls/winmm/tests/wave.c @@ -888,6 +888,13 @@ static void wave_out_test_device(int dev nameA=strdup("not supported"); }
+ rc=waveOutGetDevCapsA(device,&capsA,sizeof(capsA)); + ok(rc==MMSYSERR_NOERROR, + "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n", + dev_name(device),wave_out_error(rc)); + if (rc!=MMSYSERR_NOERROR) + return; + trace(" %s: "%s" (%s) %d.%d (%d:%d)\n",dev_name(device),capsA.szPname, (nameA?nameA:"failed"),capsA.vDriverVersion >> 8, capsA.vDriverVersion & 0xff, capsA.wMid,capsA.wPid);