what it was intended to test.
The intention was to test that src/bin/ps/utf8.c handles embedded NUL bytes
correctly, just as the other tests in the same group test the handling of
various other non-printable characters. But testing that does not work
for multiple reasons. Neither does the shell pass the NUL byte to the
called test program as intended, nor can argv[] in a C program contain
a NUL byte in the middle of an argument, simply because in the C language,
a string is defined to end at the first NUL byte. On top of all that,
even the function mbswprint() that was supposed to be tested terminates
the processing of the multi-byte input string as soon as it encounters
a NUL byte (all of which is correct behaviour).
So this particular subtest was totally bogus and only worked by accident,
for reasons completely unrelated to the intended purpose. I don't think
the test needs to be replaced by anything else. NUL bytes in the middle
of a program argument just aren't a thing in the first place.
Thanks to deraadt@ for asking what the purpose of this test_ps() call was.
"E=1 L=very_long_var shortsleep"
# test vis(3)ing
-test_ps "x$(printf \\000)x" "" "-o command" "./shortsleep xx"
test_ps "\ 1\ 2\ 3" "" "-o command" "./shortsleep \\^A\\^B\\^C"
test_ps "\ 4\ 5\ 6\a" "" "-o command" "./shortsleep \\^D\\^E\\^F\\a"
test_ps "\b x