On Alpine Linux 3.7.0, which uses musl libc, this test fails: FAIL: test-mbrtowc5.sh ======================
../../gltests/test-mbrtowc.c:106: assertion 'wc == c' failed Aborted FAIL test-mbrtowc5.sh (exit status: 134) The issue is that in the C locale, musl uses the encoding that maps 0x00..0x7F -> U+0000..U+007F 0x80..0xFF -> U+DF80..U+DFFF Whereas for older platforms it was natural to use the ISO-8859-1 encoding: 0x00..0x7F -> U+0000..U+007F 0x80..0xFF -> U+0080..U+00FF This patch fixes the test. 2018-02-24 Bruno Haible <br...@clisp.org> mbrtowc tests: Don't make assumptions about the charset the C locale. * tests/test-mbrtowc.c (main): For bytes >= 0x80, don't assume a particular mapping in the C locale. diff --git a/tests/test-mbrtowc.c b/tests/test-mbrtowc.c index a0b5231..54d52f8 100644 --- a/tests/test-mbrtowc.c +++ b/tests/test-mbrtowc.c @@ -103,7 +103,15 @@ main (int argc, char *argv[]) wc = (wchar_t) 0xBADFACE; ret = mbrtowc (&wc, buf, 1, &state); ASSERT (ret == 1); - ASSERT (wc == c); + if (c < 0x80) + /* c is an ASCII character. */ + ASSERT (wc == c); + else + /* argv[1] starts with '5', that is, we are testing the C or POSIX + locale. + On most platforms, the bytes 0x80..0xFF map to U+0080..U+00FF. + But on musl libc, the bytes 0x80..0xFF map to U+DF80..U+DFFF. */ + ASSERT (wc == btowc (c)); ASSERT (mbsinit (&state)); ret = mbrtowc (NULL, buf, 1, &state); ASSERT (ret == 1);