On 2 November 2011 13:53, Max Bolingbroke
I think the only way to fix this last case in general is to fix iconv itself, so I'm going to see if I can get a patch upstream. Fixing it for people with UTF-8 locales should be enough for 99% of users, though.
One last update on this: I've found the cause of the problem in the GNU iconv source code and submitted a bug report. I've also found out that with my patch the problem should be fixed in almost every cases (not just 99%!) because GNU iconv will correctly reject surrogates in the UTF32le<->locale encoding conversion process with EILSEQ for every non-UTF8 locale encoding that I looked at - even UTF16 and UTF32! So in conclusion I think this issue is totally fixed. Please let me know if you encounter any other problems. Max