Behavior will always be implementation dependant. It is going to depend
upon the size of ints, the size of literals (usually, but not always ints),
and how the stack frame is managed.
On the 68K it is very common to push nothing smaller than a 16 bit word onto
the stack. This keeps variables larger than 1 byte easy to access as an
address register offset. If literals are treated as 16 bits and the
smallest alignment on the stack is 2 bytes, then the code will work - since
a byte and a word take the same amount of space on the call stack. But, if
a compiler uses padding, instead of casting bytes to words, or if a literal
is larger than the granularity used for passing bytes, the called function
will produce unexpected results.
In general, whenever you are calling a function which is prototyped with
variable arguments, it is a good idea to be very exact in passed data
types.]
-jjf
-----Original Message-----
From: Richard Burmeister [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 28, 2000 3:41 PM
To: Palm Developer Forum
Subject: Re: StrPrintF Bug?
From: "Fitzpatrick, Joe" <[EMAIL PROTECTED]>
> You can just cast the literal in the StrPrintF call instead of using an
> intermediate variable: StrPrintF(display_string, "%s:%c:%s", "str1",
> (char)'R', "str");
So, the interesting question that arises is: why is it that CodeWarrior
appears to know to treat 'R' as a Char (making a typecast unnecessary) but
GCC treats it as in int (thus requiring a typecast)? In other words, why is
'R' 1 byte in CodeWarrior but not 1 byte in GCC?
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
