Re: E02 failing on Alpine / musl libc

[dana <dana@xxxxxxx>]

On Mon 16 May 2022, at 21:33, Jun T wrote:
> So I think we need/should not "fix" this, because 0xfdXX (or \ufdXX) is the
> correct representation in their "special" C loale.

I think i see the argument for not trying to do any 'special' accounting
of this locale in the shell. As far as the tests, i guess we are
technically making assumptions about the wchar values of non-'portable'
characters that POSIX says we can't actually make, but not making those
assumptions seems annoying

For the E02 test in particular, as Peter says, it isn't a multi-byte test.
If there's not anything special about the code path for xtrace
preservation that's sensitive to weird function names maybe that aspect of
the test belongs in B13, C04, or D07...?


Here is some additional context/history behind these failing tests, in
case anyone's ever looking for it later. Don't read this, you probably
don't care:

The A03 and B03 tests that Jun mentioned here have been failing on musl
since at least zsh-5.5 — probably longer (despite workers/48578 indicating
that it'd only started 'recently'), since the """special""" (lol) locale
was introduced to musl in August 2015, and made its way into Alpine very
shortly afterwards

The LC_ALL=C in the failing E02 test was introduced by me and Jun in
workers/45537+45550 to fix a similar issue i was seeing with the way the
function name ヌ was being printed by `which` on macOS Mojave. I bet i was
having this problem because i had explicitly set LC_CTYPE to a UTF-8
locale, and Jun had not yet made the change in workers/49908 to have ztst
reset that back to C like it did with LANG and LC_ALL. It does now reset
it with the others so the LC_ALL=C is probably superfluous in that respect

However, if you don't have *any* LANG/LC_* variables set, on some systems,
including Alpine, where the 'implementation-defined default locale' is
UTF-8, you can get the same behaviour i was seeing where `which` just
prints ヌ back out without any escaping

I mention that because there are basically only two possibilities on a
typical musl system (either the 'special' POSIX locale or a UTF-8 one)
and both of them will cause the test to fail as written. And also because
there might be other systems that have a UTF-8 default locale where this
test and others could fail without an explicit LC_ALL=C because ztst only
resets the locale to C if we're *not* using the default one (which i don't
think i understand the reasoning for)


dana