I'm not too familiar with GSFromUnicode(), but couldn't you treat this function in the same way that CoreBase treats ucnv_fromUnicode()? That is, pass the buffer into GSFromUnicode() with GSUniStrict option. If it returns NO, adjust the src and use NULL for dst. Would that work?
That said, I think it would be a good idea if the function you came up with would have the same signature as GSStringEncodingFromUnicode() in corebase. I'd like to one day be able to share more code between the two projects and GSStringEncodingFromUnicode() already supports that method's requirements. On Sun, Jun 9, 2013 at 9:30 AM, Fred Kiefer <fredkie...@gmx.de> 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. > > 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. > > Fred > > > On 09.06.2013 00:06, Luboš Doležel wrote: > >> GNUstep's NSString currently lacks >> getBytes:maxLength:usedLength:**encoding:options:range:**remainingRange: >> >> (added in OS X 10.5). >> >> I wanted to implement this function, but GSFromUnicode()'s behavior is >> not the best fit for this method: >> >> 1) it fails if the output buffer is too small - we don't want that in >> this case >> 2) it doesn't tell you how many input characters were converted (which >> is understandable because of 1) >> >> So I decided to use iconv() directly, which has a pitfall. I'd need to >> access static members (EntrySupported) of Unicode.m to know the iconv >> encoding's name etc. So I guess the iconv-related code (as attached) >> should be moved into Unicode.m. >> >> =============== >> >> So I have a question: is it OK to write a function with declaration: >> >> BOOL GSFromUnicodePartial(**NSStringEncoding enc, int options, unichar >> **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft); >> >> that wouldn't suffer from 1) and 2) and add it into >> Source/Additions/Unicode.m next to GSFromUnicode()? >> > > > ______________________________**_________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/**listinfo/gnustep-dev<https://lists.gnu.org/mailman/listinfo/gnustep-dev> >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
