Peter Åstrand wrote:
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 size wasn't relevant, it wouldn't be passed. There are only two options: only pass the number of bytes requested or return an error for unreasonable sizes. What is Terminal Server doing? You can check for the error return code if that's what it's doing and add it to the return values checked. If it's doing something silly like ignoring the size and overrunning the buffer, then it's broken and needs to be black listed. A page for the buffer can be allocated with a guard page after it to catch buffer overruns if necessary.
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.
waveOutGetDevCapsW lets the driver do the copy (just like old versions of windows). The driver should be checking the size and only copying that much. If it doesn't, then it broken.