On 06/09/2013 04:30 PM, Fred Kiefer wrote:
I like the idea of adding this functionality. You actual implementation
wont do as you already noticed. We also cannot use iconv()
unconditionally. I remember back in time when I first added a call to
iconv() to GNUstep we also had to introduce the configure checks for it.
And of course provide a fall back implementation for that rare case
where it isn't available. You should also have a second look at
GSFromUnicode() to notice it is trying a much better job at providing a
lossy conversion.
Oh yes, I saw that. It makes me wonder, though, why bother supporting
the non-iconv case at all, since that may cause trouble to apps that
expect conversion to work. But hey, it's already done.
You already pointed out the difference that you need to the current
implementation of GSFromUnicode(). You don't want your function to
allocate extra memory, you need it to return the index up to which it
was able to convert characters and you need a different return code that
states whether any characters where converted. Although the last could
possibly be determined by checking the returned index.
Now this sounds like a strict extension of GSFromUnicode() and I think
that in the long run these two functions should share their
implementation code. But we also need to make sure that GSFromUnicode()
is rock solid and fast, maybe we first keep them separate.
Maybe it is best if you first write your new function by extracting all
the code from GSFromUnicode() that doesn't handle memory management and
add the different return values there. Next we could think about
rewriting GSFromUnicode() on top of that. Adding the memory management
and using some pointer arithmetic. And then we test whether this is fast
enough.
I was expecting you to say something like that :-)
I don't like the current GSFromUnicode() implementation - probably
because of the GROW() macro and the non-iconv case mess.
It could be more readable to write a minimal iconv implementation for
builds without iconv, GSFromUnicode() could then only have a single
branch of code.
--
Luboš Doležel
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
