Re: [bug-gnulib] Re: iconv made easy

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> I like this.  But it would be quite wasteful on long strings;
> MB_LEN_MAX is 16 on glibc hosts.

I suspect it wouldn't be that wasteful of memory if you realloc the
result.  There may be some memory fragmentation and with some
applications this might be decisively bad; but for typical usage and a
good allocator I'd guess it wouldn't be a problem.

> This would be fast on short strings (one malloc, one iconv, one
> realloc), reasonable fast on long strings (two calls to iconv), and it
> would even handle internal bugs when iconv exceed the computed upper
> bound.

Hmmm, I don't see why it would handle internal bugs any better; if
iconv is buggy, all bets are off.

I was hoping to avoid the "two calls to iconv", by trading space for
time.  If the string is sufficiently large, the memory allocator
should "do a good job" in reallocating it (i.e., realloc shouldn't
need to copy the data).  Also, it's simpler to stick with one
algorithm rather than to have an if-then-else.

(But it's a minor issue, of course.  Also, one could always
measure....)