I want to see what happens when you feed it to inp(), but give
it a one element wchar_t outbuf buffer. Reading iconv(3) closely:
4. The output buffer has no more room for the next converted
character.
In this case it sets errno to E2BIG and returns (size_t)(-1).
A brief experiment:
iconv_t i=iconv_open("UTF-8", "WCHAR_T");
wchar_t iarr[]={0x00e8,0x00e8};
char carr[3];
char *inbuf=(char *)&iarr[0];
char *outbuf=carr;
size_t inbytesleft=sizeof(iarr);
size_t outbytesleft=sizeof(carr);
size_t n=iconv(i, &inbuf, &inbytesleft, &outbuf, &outbytesleft);
printf("Return code %d, errno=%s\n", (int)n, strerror(errno));
printf("inbytesleft=%d, outbytesleft=%d\n",
(int)inbytesleft, (int)outbytesleft);
Result:
Return code -1, errno=Argument list too long
inbytesleft=4, outbytesleft=1
iconv() converted the first wchar_t, but then stopped and terminated
with room in both input and outbuf buffers. Since iconv(), via mbr..(),
is presumably used for inp() as well, I should expect the same behavior
for encodings where multibyte sequences can produce more than one
wchar_t, if such encoding exists. I'm wondering if the current logic in
basic_filebuf handles this situation -- haven't yet deciphered it.