>Danny Epstein wrote: > >>John Crouch wrote: >> >>>Char dst[10]; >>>StrNCopy(dst, "Longer than 10 bytes", 10); > >>dst[9] = 0; > > >>As John Marshall said, check the docs. This code won't work with multi-byte >>characters because the last statement might be zeroing the second byte of a >>two-byte character. If you want your code to work with multi-byte >>characters, don't let StrNCopy see the entire buffer: >> >> Char dst[10]; >> StrNCopy(dst, "Longer than 10 bytes", 9); // save the last byte >> dst[9] = 0; >> >>The last two lines could go in either order; they operate on adjacent, but >>non-overlapping areas in memory. This works because of how StrNCopy deals >>with clipping. If a two-byte character doesn't quite fit, the "extra" byte >>is zeroed. >> >>James wrote: >> >>>Another method is to initialize dst[0] = '\0' and then use StrNCat instead >>>of StrNCopy. >>> >> >>That's what I do. >>-- >>Danny @ PalmSource >> >of course, this assumes a two byte character set...
I think this will also work for an encoding such as UTF-8, which might have three or even four bytes per character. In that case, if the string you were copying was composed of characters with the following number of bytes: <1><1><1><1><1><1><1><3> And you called StrNCopy(dst, string, 9), then what StrNCopy would do is copy the first seven bytes, and pad the remaining two bytes with nulls. >I was under the >impression that some SJIS characters are up to 4 bytes....have I been >misinformed? Yes. The Shift-JIS character encoding uses one or two bytes per character. >BTW...any chance of a Palm device using UTF-8 character sets? Yes. The major hurdle is how to allow older apps with legacy-encoded data to continue working properly on a device where the base character encoding is something different. -- Ken -- Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
