bug-gnustep
[Top][All Lists]
Advanced

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

Re: GSFromUnicode/GSToUnicode buffers [Was: [bug #4208]Applications won


From: Alexander Malmberg
Subject: Re: GSFromUnicode/GSToUnicode buffers [Was: [bug #4208]Applications won't start]
Date: Tue, 08 Jul 2003 04:31:29 +0200

When looking at this bug, I noticed in the GSFromUnicode and GSToUnicode
documentation:

(input to GSToUnicode)
""
 * <p>The slen argument is the length (bytes) of the 8-bit character
string
 * which is to be converted to 16-bit unicode.
 * This is measured in characters, not bytes.
""

and (output from GSFromUnicode)

""
 * <p>The size argument is a pointer to the initial size of the
destination
 * buffer.  If the function changes the buffer size, this value will be
 * altered to the new size.  This is measured in characters, not bytes.
""

which makes no sense to me. It seems that both of these should be in
bytes. From a quick glance, this seems consistent with the
implementations, but not with the callers. Thus, eg.

int main(int argc,char **argv)
{
    char buf[128];
    unichar chars[3]={0x41,0x42,0x80};
    NSString *str=[[NSString alloc] initWithCharacters: chars  length:
3];

    [str getCString: buf];
    printf("%s\n",buf);

    return 0;
}

breaks when run with NSUTF8StringEncoding as the string encoding, and
would give an exception if it weren't for an incorrect "result = YES;"
in Unicode.m:1623.

Assuming these are meant to be in bytes, I can fix this tomorrow.

- Alexander Malmberg




reply via email to

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