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);


Reply via email to