[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