Here is a piece of code: http://pastebin.com/GpwkwWm2 On Archlinux with glibc 2.14.1 The final output will be . Seems it works with glibc 2.13.
Please provide a self-contained testcase without any other libraries like Qt involved.
http://pastebin.com/ZXvwn70y Ok, to make the problem clear. iconv_open("UTF-8", "UTF-16") in glibc 2.13 will not remember the endianness , while glib 2.14 will remember it, no matter another iconv_open is called. glibc 2.13 output マーベラスエンターテイメント マ ==================== glibc 2.14 output マーベラスエンターテイメント ====================
Information provided.
That's the correct behavior. If you want to convert a new string you have to use iconv_close. It would be absolutely wrong to reset the setting after every iconv() call since this would make it impossible to convert a file/buffer in pieces.
Is it supposed to like this? The code use iconv_open TWICE. I support each of iconv_t have it's own state, but not affect each other, this is not true any more? As you can see, it's true in 2.13. If it's not true, it will break many library. Like I just use iconv_open("UTF-16", "UTF-8") here, and another library use iconv_open("UTF-16", "UTF-8") in another place, but I didn't aware, then it will break.
I checked in a patch.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
This can result in data corruption in multi-threaded programs. It does not result in information leaks because only the endianness flag and no other data is shared incorrectly. Commit ee190f67cc00b958a667af75dc68f3fc21611c9f is the fix (but the commit message is somewhat misleading).