Test failures on Windows WSL and Cygwin

[krader1961]

This issue is similar to #483 for OpenBSD but is instead for ksh on Windows Subsystem for Linux (WSL, aka "bash on windows") and Cygwin.

I booted Windows 10 today and updated that OS and my Cygwin installation on it. I then installed Meson and Ninja in WSL (aka “bash on windows”) and Cygwin and built and unit tested ksh. On WSL there are 7 test failures. Mostly involving signal handling which isn’t too surprising given the imperfect emulation of UNIX by WSL. There were 71 failures under Cygwin. This is the first time I’ve built/tested ksh on the two Windows platforms we need to support. Obviously there is some work to be done by someone who cares about ksh in those two Windows environments.

Note that the libast API timeouts noted here on OpenBSD also occur under Cygwin but not WSL and thus require running the unit tests with a large timeout multiplier (e.g., meson test -t5) on Cygwin to avoid a lot of false positive test failures.

[krader1961]

I took another look at the test failures on WSL. Three of them are due to the arith unit test failing the equality comparison of floating point values.

<E> arith[712]: 4.**3/10!=6.4
<E> arith[960]: mean of index array  is 5.11999999999999922 should be 5.12
<E> arith[961]: mean of associative array  is 2 should be 5.12
<E> arith[964]: dotprod of two index arrays  is 22.1999999999999993 should be 22.2
<E> arith[965]: dotprod of two identical index arrays  is 163.599999999999994 should be 163.6
<E> arith[966]: dotprod of index and associative array  is 28.1999999999999993 should be 28.2
<E> arith[967]: dotprod of two identical associaive arrays  is 163.600000000000023 should be 163.6
<W> arith[-1]: error_count = 7

It's actually surprising this test doesn't fail more often on other platforms. Why? Because you can't calculate a floating point value and reliably compare it for equality to a floating point constant. You have to compute the absolute difference of the two values and test that it is less than some epsilon value. Or, in this case, force the string representation to be rounded to the expected significant digits using printf.

[krader1961]

With the PR I just sent out for review there are zero failures on WSL modulo the usual flakey failures.

[krader1961]

As of today there are no consistent test failures on WSL and 46 consistent failures on Cygwin. Some of those are due to Cygwin quirks or bugs. For example, it gets the NaN sign bit wrong (like OpenBSD, see issue #483). Not much we can do about those failures other than skip the test on Cygwin.

[krader1961]

Closing since we're now passing all tests (most of the time) on WSL. There are still significant failures on CYGWIN. But some of them are known to fail on CYGWIN (e.g., coprocess). Other failures are due to UNIX semantics that CYGWIN doesn't provide and will need workarounds; either in the code under test or the test itself. But that is better handled via an issue for each specific failure opened by someone who cares about CYGWIN.