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

Deepayan Sarkar deepayan at stat.wisc.edu
Wed Mar 16 18:25:27 CET 2005


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/"

The libiconv equivalents look like 

ISO-10646-UCS-2
ISO-10646-UCS-4

which should be fine as they are.

Deepayan



More information about the R-devel mailing list