[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
