[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] iconv made easy
From: |
Paul Eggert |
Subject: |
Re: [bug-gnulib] iconv made easy |
Date: |
Mon, 13 Dec 2004 10:46:28 -0800 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Bruno Haible <address@hidden> writes:
>> I know the function doesn't handle embedded ASCII #0
>
> iconv() handles NUL bytes correctly; you don't need to handle them specially.
I think he was aiming for convenience at the expense of generality.
But personally I'm not sure it's worth it in this case; the caller can
simply specify a length of strlen(string)+1.
One approach that I've used in other APIs is for the caller to pass a
length of -1 (actually, SIZE_MAX) to denote the "length" of an
argument that is actually a null-terminated string. That way, the API
allows for embedded nulls, but it's still convenient/cheap for the
user to pass a null-terminated string of unknown length. This
approach is a win if the callee is already computing the length
somehow -- it saves a strlen.
Here, the strlen cannot be avoided, but perhaps the length=-1 approach
is still convenient enough to achieve Simon's goal of convenience.
> You will notice that there are two approaches to converting a string:
> a) allocate an initial buffer and extend it as needed, stopping and
> restarting iconv() each time a realloc is needed,
> b) call iconv() once to determine the length and then once again for
> filling the result string.
Good point. Generally speaking, in GNU code we are willing to trade
space for speed (within reason, of course) so I guess (a) would be
preferable, typically.
But in this case isn't there a 3rd option that is even faster?
Something like this:
c) Use MB_LEN_MAX to calculate an upper bound for the size of the
output buffer (from the input buffer size). Allocate a buffer of
that size, invoke iconv(), and then realloc the buffer once
iconv() finishes and you know the correct size.
This is nearly as simple as (b). Overall, I'd expect it to be faster
than either (a) or (b), assuming a decent memory allocator.
[bug-gnulib] Re: iconv made easy, Simon Josefsson, 2004/12/13