IMHO, if the input contains possibly embedded nulls, it is then simply NOT "null-terminated string". The concept of null-terminated string should only be used with data without embedded nulls, such as ASCII, EUC-JP, EUC-CN, UTF-8, and so on. If this is not the case (as in UTF-16), using data length along with the data make your life much easier.
It is a design choice. I think the iconv way is just OK. The only problem I see is that it lacks a way to query the necessary output buffer size, but that could be done within the current framework of libiconv, say, doing the count when inbuf is non-NULL, outbuf is NULL, and *outbytesleft is 0.
Best regards,
Wu Yongwei
To do this stuff with iconv is much harder and in some cases impossible (i.e. topic of this post). The idea behind encdec [1] is to make what 90% of what people want to do really easy.
The problem I'm faced with right now is that encdec is just non-standard. It requires dragging 900K of code tables from libiconv into the mix. Right now I have a project that I want to be very plain
and portable so I want to swap out my encdec routines with iconv
ones. But the code is getting ugly. I'll have to scan the src to
determine it's length in advance. That's slow and dangerous.
Mike
[1] http://www.ioplex.com/~miallen/encdec/
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
