Bruno Haible <[email protected]> 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 _______________________________________________ Help-libidn mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-libidn
