Date: Thu, 30 Jul 2020 03:43:40 +0200 From: Bruno Haible <bruno@...sp.org> To: Rich Felker <dalias@...c.org> Cc: "A. Wilcox" <awilfox@...lielinux.org>, bug-bison@....org, musl@...ts.openwall.com, bug-gnulib@....org Subject: Re: 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 glibc behavior for iconv of returning an error if a > character from the input is not exactly representable in the output, > rather than making replacements and returning the number of inexact > conversions made. 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 output), - those that are better not presented to the user, if the programmer has specified a fallback (for example, replacing all non-ASCII characters with NUL, '?', or '*'). The standards don't help in making the distinction. Therefore whether you consider said glibc and libiconv behaviour as "non-conforming" or not is irrelevant. I have now adjusted the code to handle musl libc better. Bruno
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.