[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Jul 2020 11:02:25 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Bruno Haible <bruno@...sp.org>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com,
"A. Wilcox" <awilfox@...lielinux.org>, bug-bison@....org,
bug-gnulib@....org, Arjun Shankar <ashankar@...hat.com>
Subject: Re: 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 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.
Could you sketch briefly what you need? We have identified some issues
with the existing iconv interface. If we add an enhancement, it would
make sense to cover these requirements.
Thanks,
Florian
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.
