When you evaluate the expression (theChar == MY_CHAR), C promotes both
variables to integers. MY_CHAR is an integer constant already, so it
stays 0x80 (= 128). But char variables in many (but not all) compilers
default to "signed", so 0x80 as an unsigned (2's complement) 8 bit
integer is -128. This is promoted to an integer (that is, full word
sized value), and then -128 is compared to 128 and they're not equal.
The printf has the same problem. Actually, you didn't show the
declaration of cTemp, but if it's a char, then when it's evaluated as
the argument to StrPrintF, it's promoted to an integer, again becomes
-128, and that's what's printed.
If you're using chars to hold values larger than 0x7F, you should
declare them "unsigned char". The PalmOS header Common.h defines a
typedef "Byte" which can also be used (although I wish they'd called it
"UByte" to be clear that it's intended to be unsigned).
--Mark
Michael McFarland wrote:
>
> Greetings all,
>
> I am getting started w/ Palm programming, and this is my first post.
> In working w/ serial communication I've stumbled on something that seems
> very strange to me. Consider the following code:
>
> #define MY_CHAR 0x80
>
> my_fun() {
> char theChar;
> char theString[10];
> int theBoolean;
>
> cTemp = 0x80;
>
> theBoolean = (theChar == MY_CHAR); // theBoolean is set to 0
> StrPrintF(theString, "%x", cTemp); // theString is set to
> "FFFFFF80", which is 4294967168 or -128
> }
>
> From what I've seen so far, cTemp is being set to a 4-byte value with
> three 'FF' bytes preceding the byte I specified. But the CW help files say
> a char is 8 bits, as I would expect on any system not using Unicode. So
> what am I missing?
>
> Michael McFarland
