[EMAIL PROTECTED] wrote:
> the following code does not work
> char buf[16];
> StrPrintF(buf,"telephone%c", 's');
[..]
> I am using 4 byte option
Actually, there's no real reason for you to expect this to work, and it's
nothing to do with MSL, Unicode, or "portal types" like UINT, DWORD etc.
When you set the 4 byte ints option, you decided not to conform to the
Palm OS ABI, and so all bets are off.
Generally this won't cause problems because most API functions are declared
in terms of shorts (*Int16) and longs (*Int32) rather than ints. But in
ISO C all variants of char and short are promoted to *int* when they're
prototyped as `...' (sections 6.3.2.2, 6.2.1.1), so if int is suddenly
32 bits when things like StrPrintF are expecting 16 bits you can expect
to have problems with varargs functions like StrPrintF.
Since StrPrintF isn't part of MSL, but instead is set in concrete in your
ROM, there's no way to get it to expect 32 bit ints. Explicitly casting
to any of char, short, Int8, Int16 won't help because all these will get
implicitly promoted to int due to the default argument promotions caused
by `...'.
I can think of two ways to work around this:
* Don't break the ABI -- don't set the 4 byte int option, and use long
when you mean long.
* Pass your vararg parameters as structs instead:
struct { short sh; } x;
x.sh = 's';
StrPrintF (buf, "telephone%c", x);
Structs are not subject to the default argument promotions, and short
looks like what StrPrintF is expecting to get when you pass a char (but
of course this code isn't portable).
> StrPrintF(buf,"telephone %ld", 1234);
Here you know you're passing 32 bits to StrPrintF and so you pretend that
it's a long (%ld), because StrPrintF knows that that is a 32 bit int.
Unfortunately, there's no corresponding "%lc" notation.
John "language lawyers 'r' us"
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
