bug-gnu-libiconv
[Top][All Lists]
Advanced

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

Re: [bug-gnu-libiconv] Re: Libidn 1.13 test tst_toutf8 fails on Solaris


From: Simon Josefsson
Subject: Re: [bug-gnu-libiconv] Re: Libidn 1.13 test tst_toutf8 fails on Solaris 8 Sparc w/Sun Studio 11
Date: Tue, 24 Mar 2009 08:25:24 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Hi Dagobert,
>
>> It looks like the usual 646 / ASCII problem on Solaris:
>> 
>> build8s% ./tst_toutf8 -v
>> PASS: stringprep_locale_charset == 646
>> zsh: segmentation fault (core dumped)  ./tst_toutf8 -v
>
> Yes, according to the source code [1] the result of nl_langinfo(CODESET) is
> being used as an argument to iconv_open, and this does not work well in the
> GNU libiconv versions released so far.
>
>> Bruno, I guess this will be fixed with the special build-in for Solaris
>> in the next libiconv-release we talked about some month ago?
>
> Yes it will. Simon, for reference, the thread is in [2].

Thanks for the pointer.  As far as I can tell, you do agree that
nl_langinfo(CODESET) passed as an argument to iconv_open should work, at
least internally on each platform.  Is that right?  If so, I don't see
anything we can do about this in libidn (except to fix the segmentation
fault above, but that is already done).  Or is there a better way to
find out what string to pass to iconv_open for the locale charset than
using nl_langinfo(CODESET)?  I have been worried about nl_langinfo not
being thread safe, and thus inappropriate for use in a library; it is a
minor problem that I haven't been able to solve.  If there is a better
approach than nl_langinfo, libidn could use it.

/Simon

> [1] 
> http://www.google.com/codesearch/p?hl=de#XR0CgL_6lJ8/libidn-0.1.13/toutf8.c&q=stringprep_locale_to_utf8
> [2] http://lists.gnu.org/archive/html/bug-gnu-libiconv/2008-04/msg00003.html




reply via email to

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