gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementing NSString getBytes


From: Richard Frith-Macdonald
Subject: Re: Implementing NSString getBytes
Date: Mon, 10 Jun 2013 10:07:50 +0100

On 10 Jun 2013, at 09:49, Luboš Doležel <address@hidden> wrote:

> On Mon, 10 Jun 2013 09:37:51 +0100, Richard Frith-Macdonald wrote:
>> On 10 Jun 2013, at 08:57, Luboš Doležel <address@hidden> wrote:
>> 
>>> On Mon, 10 Jun 2013 07:58:29 +0100, Richard Frith-Macdonald wrote:
>>>>> 1) it fails if the output buffer is too small - we don't want that in 
>>>>> this case
>>>> 
>>>> Well, that depends on what arguments you pass to it ... if you
>>>> provide it with a zone in which to allocate memory, it will allocate
>>>> memory to make a bigger output buffer if necesary.
>>> 
>>> Not quite. The caller of getBytes supplies his own buffer.
>>> Should the buffer not be sufficient and GSFromUnicode() allocates own 
>>> memory, I'd then have trouble finding out how many bytes to copy to 
>>> caller's buffer *without* splitting an UTF-8 character in the middle (for 
>>> example).
>> 
>> So there is no problem with memopry allocation ... if you want
>> GSFromUnicode() to allocate more memory, you can tell it to do that,
>> and if you don't want it to, you can tell it to do that too.
> 
> The documentation says it indicates failure if there isn't enough space in 
> the output buffer, which makes it indistinguishable from encountering an 
> inconvertible character in strict mode.
> 
> getBytes fails in the latter case, but succeeds in the former case.

I think you are not looking at the whole documentation and/or code:

> If GSUniShortOk is set, the function will return a buffer containing
> any decoded characters even if the whole conversion fails.

This means that it will convert and return as many characters as it can (if you 
specify the GSUniShortOk option).

What it doesn't currently do is return the number of converted/remaining 
characters in the source, only the number of bytes produced in the destination, 
which is why I'm saying we should just modify it to return the number of source 
characters not converted.  This seems to me a very minor (and logical) 
extension of existing code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]