[Top][All Lists]

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

Re: [Monotone-devel] Re: Why is utf8 type _NOVERIFY, and other vocab stu

From: Zack Weinberg
Subject: Re: [Monotone-devel] Re: Why is utf8 type _NOVERIFY, and other vocab stuff.
Date: Thu, 15 Feb 2007 09:38:02 -0800

On 2/15/07, Lapo Luchini <address@hidden> wrote:
Nathaniel Smith wrote:
> (Also,
> there were reports that the _best_effort code didn't actually work
> with lots of broken iconv's found in the wild...)

On Derek's super-laptop "UTF8 to ASCII//IGNORE//TRANSLIT" actually
failed just like it was plain "UTF8 to ASCII". AFAIR it was a Gentoo.

The //IGNORE and //TRANSLIT features are glibc / GNU libiconv
specific, but I would have thought that they were available in recent
Gentoo (they've been around since 2001 give or take).

The real problem, though, is that an awful lot of non-GNUish systems
have iconv implementations that are useless.  I mean _useless_.  They
implement hardly any conversions at all.  We have to have the "(list
of names for ASCII) <-> UTF8" shortcut for _correctness_, not just for
speed; real live systems don't support conversion between their own
locale's name for ASCII and UTF-8.   *headdesk*

It might be possible to bundle GNU libiconv, but I hesitate to
recommend that because I recall its being another Haible/Drepper build
system monstrosity like intl.

I'm willing to debug it further, if someone gives me access to a system
in which I can verify the failure... or, even easier, I could create a
smallish program that only has a fixes UTF8 string inside itself and ask
on the command line for a charset and simply call the iconv function
with those 2 parameters...

Many systems have an iconv(1) command line utility that may be helpful here.


reply via email to

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