dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...

[Robert Reif]

Francois Gouget wrote:

> On Thu, 4 Nov 2004, Robert Reif wrote:
>
>> Jakob Eriksson wrote:
>>
>>>
>>> As shown by:
>>> http://test.winehq.org/data/200411021000/2000_IDWASEMPTY_1/winmm:capture.txt 
>>>
>>> capture.c:571:found 1 WaveIn devices
>>> capture.c:302:  0: "Avance AC'97 Audio" 
>>> (\\?\pci#ven_1106&dev_3059&subsys_00000000&rev_10#3&61aaa01&0&8d#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave) 
>>> 5.0 (1:101)
>>> capture.c:305:     channels=65535 formats=00fff
>>> capture.c:364: Test failed: waveInOpen(0): opening the device with 2 
>>> MHz sample rate should fail:  rc=MMSYSERR_NOERROR(The specified 
>>> command was carried out.)
>>
>>
>> That's a driver bug.
>
>
> Driver bug or not, there are Windows systems that behave this way 
> (precisely those that have these buggy drivers).
> The real question is:
>
> Is there a Windows application that crashes because of this?
>
> If not then IMHO we should consider this behavior to be unspecified 
> and thus not test it.
>
>
It is a valid test and it did find a real bug.  The bug just
happened to be in a real Windows system.

Wine at one point failed on this same test with certain drivers
and removing it may allow a regression in wine to be reintroduced.

I'm not sure I like the argument that if there is no real Windows 
application
that crashes on the bug, then it should not be considered a bug.  I 
think it's
more proper to write tests that ensure that wine implements the Windows
API as faithfully as possible.  This is not a case of undefined behavior but
a real bug in a specific Windows driver.  Following this logic will allow
programs developed with winelib with real bugs to run in wine but fail
when ported to Windows.  Just because programming bugs caught by
Windows during development on Windows didn't make it into the final
product doesn't mean wine should ignore those same bugs because they
don't happen.  It's limiting the use of winelib as an alternative 
development
platform for Windows applications.

Removing the test so it passes on a Windows system with a real bug is
not the right thing to do for a wine regression test.  The test is there to
find bugs and that's what it did.