This is the mail archive of the
mailing list for the glibc project.
Re: regression caused by fix of bug #13691
On Tue, May 15, 2012 at 10:35 AM, Ryan S. Arnold <email@example.com> wrote:
> On Mon, May 14, 2012 at 5:46 AM, Bruno Haible <firstname.lastname@example.org> wrote:
>> I wrote:
>>> I therefore propose to
>>> ? - revert Tulio's "fix",
>>> ? - remove vi_VN.TCVN/TCVN5712-1 from localedata/SUPPORTED, and
>>> ? - resolve BZ #13691 as "Won't fix".
>>> Patch attached.
>> Of course the unit test that exercises the vi_VN.TCVN locale also has to
>> be removed (otherwise it will fail). Revised patch attached.
> With the impending removal of vi_VN.TCVN what is the
> fallback/alternate locale that should be used instead?
Thank you for the analysis and help!
I was not aware that the glibc implementation of multi-byte character
to wide-character conversions did not support state-dependent
encodings. I fully trust your opinion given your past experience with
However, the source and testsuite appear to indicate that
state-dependent and stateless encodings are supported, are the
comments wrong or am I misunderstanding something?
I'm trying to learn about locales as quickly as possible but there is
a lot to know both technically and about the implementations.
Do you have an answer to Ryan's question? What is the effect of
removing a locale from localedata/SUPPORTED? Is it still installed? Is
it still available for use with iconv but remains broken. I would like
to understand, as Ryan does too, the implications of your patch.
- It was mentioned in  that vi_VN.TCVN is the only state-dependent
character encoding being used by Debian and that it's broken.
- LFS notes in  that vi_VN.TCVN is broken and removes it from
- The FreeDesktop standard in  says GLIBC doesn't support vi_VN.TCVN.
It certainly seems like your suggestion is the right way forward, I
just want to understand it in a little more detail.