ast: test failures in OpenBSD

These are the other test failures in OpenBSD, after the recent fixes of #429 (zzz problem) and #443 (vfork problem). I attach the test log from commit f5b9c64 in OpenBSD 6.3 on amd64.

Attachment: testlog.txt

arith, comvario, treemove: bug in OpenBSD

  7/153 arith                                   FAIL     0.57 s
--- stderr ---
<E> arith[592]: printf '%g\n' Nan failed -- expected nan, got -nan
<E> arith[594]: print -- $((Nan)) failed -- expected nan, got -nan
<E> arith[592]: printf '%g\n' -Nan failed -- expected -nan, got nan
<E> arith[594]: print -- $((-Nan)) failed -- expected -nan, got nan
<W> arith[-1]: error_count = 4

 34/153 comvario                                FAIL    10.15 s
--- stderr ---
/tmp/ksh.comvario.uR9mZ3s/comvario.sh: warning: -lm does not support signbit(-Na
N)
<E> comvario[241]: Expected ...my_nan=nan... == ...my_nan=-nan...

137/153 treemove                                FAIL     0.29 s
--- stderr ---
<E> treemove[328]: typeset -m not working when passed a reference to an local argument from a calling function
<E> treemove[67]: typeset -C -a c.ar=((typeset -l -E i=-nan) (typeset -l -E i=inf) (typeset -l -E i=24) (typeset -l -E i=4) (typeset -l -E i=2) (typeset -l -E i=1) (typeset -l -E i=-1) (typeset -l -E i=-inf)) is not idempotent
<W> treemove[-1]: error_count = 2

Not a bug in ksh. This is a bug in OpenBSD/amd64, where libc functions like strtod(3) flip the sign so “nan” becomes -nan and “-nan” becomes nan. I hacked my libc to fix strtod(), but I didn’t fix strtold(), so I still see failures. I sent a bug report to OpenBSD: https://marc.info/?l=openbsd-bugs&m=152391654313171&w=2

directoryfd: no /proc, no /dev/fd/11/*

 43/153 directoryfd                             FAIL     2.11 s
--- stderr ---
<E> directoryfd[116]: ...got 'mkdir: /proc/53773/fd/11//test1: No such file or directory'
<E> directoryfd[116]: ...got 'mkdir: /proc/self/fd/11//test1: No such file or directory'
<E> directoryfd[116]: ...got 'mkdir: /dev/fd/11//test1: Not a directory'
<E> directoryfd[116]: ...got 'mkdir: /proc/17630/fd/11//test1: No such file or directory'

OpenBSD has no /proc directory. It does have /dev/fd/11, an fd(4) device node. To open /dev/fd/11 is to duplicate file descriptor 11. Paths like /dev/fd/11/test1 don’t work because they don’t open /dev/fd/11, so /dev/fd/11 is still a device node, not a directory.

OpenBSD doesn’t have these paths, but the test expects them to work. Does ksh emulate these paths? Perhaps mkdir must be a builtin and not /bin/mkdir?

pty: problem with pty or vi mode

 89/153 pty                                     FAIL    21.12 s
--- stderr ---
<E> pty[395]: POSIX sh 251(C): line 19: expected "echo repeat-2", got EOF
<W> pty[-1]: error_count = 1

This uses pty to test vi mode in ksh, set -o vi. I tried entering vi mode. Commands like /, ?, n, N seem to work as well in ksh as in other shells. I don’t know if another command in vi mode is broken, or if pty is broken.

sh_match: no ulimit -M or -V

113/153 sh_match                                FAIL     0.45 s
--- stderr ---
<E> sh_match[420]: test_xmlfragment1/0/testfile1.xml: Expected empty stderr, got $'test1_script.sh[2]: ulimit: as: is read only\ntest1_script.sh[3]: ulimit: vmem: is read only'
<E> sh_match[420]: test_xmlfragment1/1/testfile2.xml: Expected empty stderr, got $'test1_script.sh[2]: ulimit: as: is read only\ntest1_script.sh[3]: ulimit: vmem: is read only'
<W> sh_match[-1]: error_count = 2

The “as:” error comes from ulimit -M, and “vmem:” from ulimit -v, in the line:

	# memory safeguards to prevent out-of-control memory consumption
	ulimit -M \$(( 1024 * 1024 ))
	ulimit -v \$(( 1024 * 1024 ))
	ulimit -d \$(( 1024 * 1024 ))

OpenBSD doesn’t support ulimit -M and -v. Now ksh knows this, so ulimit -a prints “not supported” for both -M and -v. The test doesn’t know to ignore the errors.

In OpenBSD, ulimit -d controls memory: getrlimit(2) says of RLIMIT_DATA,

The maximum size (in bytes) of the data segment for a process; this includes memory allocated via malloc(3) and all other anonymous memory mapped via mmap(2).

In some other systems, RLIMIT_DATA only controls sbrk(2), and different limits control other allocators like mmap(2).

sigchld: unknown problem

118/153 sigchld/shcomp                          FAIL    25.10 s
--- stderr ---
<E> sigchld[202]: 99416 already finished and reaped
<W> sigchld[-1]: error_count = 1

In this run, sigchld/shcomp failed but sigchld succeeded. Some failures that don’t happen in every test run; this seems to be one of them.

signal: no sigqueue(2)

119/153 signal                                  FAIL    82.21 s
--- stderr ---
<E> signal[546]: ${c.car[0].value.q} is  0 but should be 4
<E> signal[547]: ${c.car[1].value.q} is  0 but should be 5
<W> signal[-1]: error_count = 2

OpenBSD doesn’t have sigqueue(2), so ksh doesn’t use it. The test tries to pass 4 and 5 through sigqueue(2); the values get lost. One might modify the test to accept systems where both values are 0.

variables: locale “x” is valid

142/153 variables                               FAIL     7.22 s
--- stderr ---
<E> variables[713]: LC_ALL=x failed -- expected locale diagnostic
<E> variables[715]: LC_ALL=x failed -- expected '', got 'x'
<E> variables[717]: LC_ALL=C; LC_ALL=x failed -- expected 'C', got 'x'
<E> variables[713]: LC_CTYPE=x failed -- expected locale diagnostic
<E> variables[715]: LC_CTYPE=x failed -- expected '', got 'x'
<E> variables[717]: LC_CTYPE=C; LC_CTYPE=x failed -- expected 'C', got 'x'
<E> variables[713]: LC_MESSAGES=x failed -- expected locale diagnostic
<E> variables[715]: LC_MESSAGES=x failed -- expected '', got 'x'
<E> variables[717]: LC_MESSAGES=C; LC_MESSAGES=x failed -- expected 'C', got 'x'
<E> variables[713]: LC_COLLATE=x failed -- expected locale diagnostic
<E> variables[715]: LC_COLLATE=x failed -- expected '', got 'x'
<E> variables[717]: LC_COLLATE=C; LC_COLLATE=x failed -- expected 'C', got 'x'
<E> variables[713]: LC_NUMERIC=x failed -- expected locale diagnostic
<E> variables[715]: LC_NUMERIC=x failed -- expected '', got 'x'
<E> variables[717]: LC_NUMERIC=C; LC_NUMERIC=x failed -- expected 'C', got 'x'
<W> variables[-1]: error_count = 15

All these tests expect that “x” isn’t a valid locale name. OpenBSD takes “x” as a valid alias of “C”, because setlocale(3) says,

The syntax and semantics of the locale argument are not standardized and vary among operating systems. On OpenBSD, if the locale string ends with “.UTF-8”, the UTF-8 locale is selected; otherwise, the “C” locale is selected, which uses the ASCII character set. If the locale contains a dot but does not end with “.UTF-8”, setlocale() fails.

So “x.x” is a bad locale name in OpenBSD. One might assign bad=x.x and test LC_ALL=$bad. If different systems needed different bad names, then one might check $(uname) and assign bad=x, bad=x.x, or another value.