We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Why does sprintf generate a Null when sprinting extended character 253(decimal) in to a a string variable? i.e.
sprintf(s,"%s","ý");
I don't know, but you're on pretty dodgy ground using string literals containing characters that aren't 'real' ASCII ie >127. Could you use: sprintf(buff,"%c",253); instead? Stefan
Thanks for the suggestion. Only problem is, I use the extended characters for "special" symbols (button shapes etc.) on an LCD and these could be part of a full text string. This is the reason I used the %s format rather than %c. e.g. "1234ý678" the result data string would be: 31,32,33,34,36,37,38 I used sprintf in my example, but it was passing the string as a parameter to a function that brought the problem out. It was coincidence that sprintf resulted in the same problem. As stated in my original thread, all the other extended characters work! Why is 253 so different? Steve
Try "blah\x0FDblah" instead of "blahýblah". Any character with code above 127 is not guaranteed to work. Hexadecimal and octal codes were designed for that. - mike
Interesting. For me, sprintf (buf, "%s", "375"); works as expected, as do sprintf (buf, "%s", "\375"); sprintf (buf, "%s", "\xFD"); How do you input this character into your string literal? Is it some sort of Unicode (or other "wide" character) value that has a leading null as part of the 16 bits?
are you sure that the character which displays as 'ý' here actually has code 253?? Maybe, in the font you're using, this is how it displays a NUL?!
All, Thanks for the suggestions. First time I've used the Discussion Forum and it's been a great help! I have tried Mike's solution and that works. Andrew, yes it definitely put the hex value 0xFD in to the string. Drew, I entered the code using Alt 0253 (in uV2) or Alt 253 (in uV1). Steve