[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] improve locale handling in m4/wcwidth.m4

From: kc . REMOVE . SPAM
Subject: Re: [PATCH] improve locale handling in m4/wcwidth.m4
Date: Tue, 14 Jul 2009 17:43:34 +0200
User-agent: Opera Mail/9.64 (Linux)

Dear Bruno,

On Mon, 13 Jul 2009 23:46:29 +0200, Bruno Haible <address@hidden> wrote:

the attached patch solves two problems with the current version of
m4/wcwidth.m4 (serial 14). However, those two problems are so closely
related that I chose to attack them in one patch.

On which platform did you encounter a wcwidth that does not work?

sorry, I did not phrase that out clearly enouch in the original post.
I did not encounter a wcwidth that did not work.
And the patch does not try to work around a failing wcwidth.

The patch addresses a non-conservative test within an m4 function.

What's your platform?

My platform is x86_64-pc-linux-gnu. But that is misleading, as the platform is not relevant. To me, the test within the m4 file is buggy or at least not conservative--regardless of the platform.

The test in the m4 file assumes that any wcwidth works. Unless it can load the “fr_FR.UTF-8” locale. Then it performs a simple tests.

Why should the presence of the “fr_FR.UTF-8” locale trigger the test?

However, I was cross-compiling gettext-0.17 on x86_64-pc-linux-gnu for i686-pc-linux-gnu. gettext did not compile because it did not use the system wchar.h, but some other variant provided with the gettext's source tarball. The cause was that gettext's configure was “guessing no” when checking whether or not wcwidth would work for my cross i686-pc-linux-gnu.

Looking at m4/wcwidth.m4 file showed that the reason is the cross-compilation and by setting “gl_cv_func_wcwidth_works” everything works now.

Nevertheless, the (unpatched) m4/wcwidth.m4 looks severly flawed.
It assumes that any wcwidth works. Unless it can load the “fr_FR.UTF-8” locale. Then it performs a simple tests.

On my x86_64-pc-linux-gnu, I use UTF-8 but do not have a “fr_FR.UTF-8” locale. Nevertheless the (unpatched) gl_FUNC_WCWIDTH guessed that my wcwidth works with UTF-8 locale.

What if I'd sit on a platform *without* a properly working UTF-8 and remove the fr_FR.UTF-8 locale?

[ wcwidth test within m4/wcwidth.m4 ]
There is a hidden assumption that a system either has many UTF-8
locales [...] or none at all [...]

This hidden assumption fails for me. And I'd argue that I am not the only one (E.g.: gentoo encourages people to only build the locales they use [1]).

And even if all platforms with faulty wcwidth provide fr_FR.UTF-8. What happens if I remove the fr_FR.UTF-8 locale from a system where wcwidth misbehaves? In the unpatched variant, the test then asserts that wcwidth works correctly eventhough it does not work correctly.

Kind regards,

P.S.: Maybe it would be better to throw the patch away, find some canonical way to find _any_ UTF-8 locale and then use this locale instead of fr_FR.UTF-8?

[1] http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3_pre10

Do _not_ remove the ".REMOVE.SPAM" in the address.
It's a catch for too smart address harvesters

reply via email to

[Prev in Thread] Current Thread [Next in Thread]