Re: [musl] Building Bison 3.7 with musl (was Re: portability issues with unicodeio)

* Bruno Haible: > Yes and no. The code is not making assumptions about a particular iconv() > implementation. But it needs to distinguish two categories of replacements > done by iconv(): > - those that are harmless (for example when replacing a Unicode TAG > character U+E00xx with an empty

Re: [musl] Building Bison 3.7 with musl (was Re: portability issues with unicodeio)

[CCing bug-gnulib] Rich Felker wrote: > I don't think the '*' has anything to do with it being a bullet > character. It's just the implementation-defined replacement character > musl's iconv uses. Correct. > I would guess the code in bison and coreutils printf is assuming the > non-conforming gl

Re: Building Bison 3.7 with musl (was Re: portability issues with unicodeio)

[CCing bug-gnulib. Dropping musl list from CC.] A. Wilcox wrote in : > Seeing some weird behaviour here building Bison 3.7 on musl libc. > > Something seems to be "intelligent" enough to know that \u2022 is a > bullet character, and is replacing i

Re: portability issues with unicodeio

> * tests/test-unicodeio.c (main): In the "C" locale, expect either the > UTF-8 output or the specified fallback. Now that we have a unit test, I see that the test fails on NetBSD 9.0. This patch fixes it. 2020-07-10 Bruno Haible unicodeio: Fix wrong result on NetBSD.

Re: portability issues with unicodeio

Hi Bruno, > Le 9 juil. 2020 à 17:31, Bruno Haible a écrit : > > Kiyoshi KANAZAWA wrote: >> make check passed both on Solaris 11.3 & 11.4. > > Oh, I see. So my unit test was not complete. > >>> It is succeeds this test, then what is the difference between the >>> coreutils printf program and th

Re: portability issues with unicodeio

Kiyoshi KANAZAWA wrote: > make check passed both on Solaris 11.3 & 11.4. Oh, I see. So my unit test was not complete. > > It is succeeds this test, then what is the difference between the > > coreutils printf program and the test-unicodeio.c program? Both call > > setlocale (LC_ALL, ""). > > I d

Re: portability issues with unicodeio

Hi Bruno, >   https://haible.de/bruno/gnu/testdir-unicodeio.tar.gz ? make check passed both on Solaris 11.3 & 11.4. > It is succeeds this test, then what is the difference between the > coreutils printf program and the test-unicodeio.c program? Both call > setlocale (LC_ALL, ""). I do not unde

Re: portability issues with unicodeio

Hi Kiyoshi-san, > FYI, also checked on Solaris 11.4 x86/x64, and had the same result. Whereas I checked Solaris 11.3 (x86 and sparc) and Solaris 11.4 (x86), and had no issue with the newly added unit test. Can you please configure, build, and 'make check' the package https://haible.de/bruno/gn

Re: portability issues with unicodeio

Hi Bruno, Hi Akim, FYI, also checked on Solaris 11.4 x86/x64, and had the same result. $ uname -a SunOS hidden 5.11 11.4.0.15.0 i86pc i386 i86pc $ LC_ALL=C $coreutilsbin/printf '\u2022\n' | od -t x1 000 3f 0a 002 $ LC_ALL=en_US.UTF-8 $coreutilsbin/printf '\u2022\n' | od -t x1 000

Re: portability issues with unicodeio

- Original Message - > From: Bruno Haible > To: bug-gnulib@gnu.org > Cc: Akim Demaille ; Kiyoshi KANAZAWA > ; Bison Bugs > Date: 2020/7/9, Thu 03:08 > Subject: Re: portability issues with unicodeio > > Hi Akim, Kiyoshi-san, > >> Unfortunately on Kiyoshi's env

Re: portability issues with unicodeio

Hi Akim, Kiyoshi-san, > Unfortunately on Kiyoshi's environment (SunOS hidden 5.11 11.3 i86pc i386 > i86pc, > GCC 9.3.0) we get '?' instead of '.' in the C locale. We get a genuine ASCII > '?', it's not some fallback from the terminal which fails to display the > character. And we properly get t

portability issues with unicodeio (was: [GNU Bison 3.6.90] testsuite: 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 196 220 221 228 244 245 246 249 250 251 252 25

Hi! Bison uses gnulib's unicodeio module to emit bullets (•) portably, with a fallback to '.'. It's implemented this way (src/gram.h): > /* Fallback in case we can't print "•". */ > static inline long > print_dot_fallback (unsigned int code _GL_UNUSED, > const char *msg _GL_