From ripley at stats.ox.ac.uk  Wed Mar 16 18:34:25 2005
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed Mar 16 18:34:34 2005
Subject: [Rd] minor iconvlist() bug in r-devel
In-Reply-To: <200503161125.27681.deepayan@stat.wisc.edu>
References: <200503160918.53650.deepayan@stat.wisc.edu>
	<200503161047.35764.deepayan@stat.wisc.edu>
	<Pine.LNX.4.61.0503161650070.368@gannet.stats>
	<200503161125.27681.deepayan@stat.wisc.edu>
Message-ID: <Pine.LNX.4.61.0503161730310.5014@gannet.stats>

On Wed, 16 Mar 2005, Deepayan Sarkar wrote:

> On Wednesday 16 March 2005 10:57, Prof Brian Ripley wrote:
>> On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
>>> On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote:
>>>> That file is created by
>>>>
>>>> $(top_builddir)/library/$(pkg)/iconvlist: most
>>>>          @iconv -l > $@ 2> /dev/null || touch $@
>>>>
>>>> What version of iconv -l is that produces such a list?  That in
>>>> glibc 2.3.4 does not produce the header when redirected.
>>>
>>> I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't
>>> help.
>>
>> I found an old RH9 system that did the same thing.
>>
>>>> Your fix is not safe: iconv in libiconv produces items separated
>>>> by space or newline.  Looks like we will have to work harder to
>>>> distinguish the two.
>>>
>>> Can anything with a lowercase letter be safely rejected? That would
>>> bring the spurious names down to 2 (FROM and TO).
>>
>> No.  I think what we can do is to look to see if most lines end in
>> //, and if so assume glibc format.
>
> Yes, that should be good enough.  Actually, the matches intended by the
> glibc version seems to be those that look like "^.*/.*/$". In
> particular, there are names like
>
> ISO-10646/UCS2/
> ISO-10646/UCS4/
> ISO-10646/UTF-8/
> ISO-10646/UTF8/
>
> which should end up as
>
> ISO-10646/UCS2, ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8
>
> but currently end up as
>
> [545] "ISO-10646/UCS2/"        "ISO-10646/UCS4/"
> [547] "ISO-10646/UTF-8/"       "ISO-10646/UTF8/"

I don't think so, and neither variant is in the human-readable list. The 
only documentation I have seen (a comment which said this, and `don't 
ask') suggests that only those ending in // are valid, and indeed that is 
all that gets through the most recent change.

> The libiconv equivalents look like
>
> ISO-10646-UCS-2
> ISO-10646-UCS-4

You only need UCS-2 and UCS-4, with LE and BE variants.


-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


[Rd] minor iconvlist() bug in r-devel
Prof Brian Ripley