Re: Implementing NSString getBytes

[Chan Maxthon]

Slow to run but quick & dirty: use -[NSString substringInRange:] to cut the 
string up, convert them into NSDatas and dump from them?

发自我的 iPhone

在 2013-6-9，6:16，Luboš Doležel <address@hidden> 写道：

> Unfortunately not. It would then be difficult to determine the "leftover" 
> output argument's value.
> 
> Also, when converting to UTF for example, there would be a risk of cutting a 
> UTF sequence in the middle if it doesn't fit into the "buffer" argument when 
> copying it from NSData.
> 
> Simply put, getBytes is more advanced than other NSString's methods.
> 
> Lubos
> 
> 
> 
> Dne 9. června 2013 0:08:40 Chan Maxthon <address@hidden> napsal:
>> Can you just dump it from -[NSString dataUsingEncoding:] which is way 
>> simpler?
>> 
>> 发自我的 iPhone
>> 
>> 在 2013-6-9，6:06，Luboš Doležel <address@hidden> 写道：
>> 
>> > Hi,
>> > 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()?
>> > -- Luboš Doležel
>> > <getBytes.patch>
>> > _______________________________________________
>> > Gnustep-dev mailing list
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
>