I only have one thing to say: "Wow!"
That's a very interesting insight to how C compilers actually work. Do you
mind if I ask u what u do for a living? :)
Regards,
Gee.
"John Marshall" <[EMAIL PROTECTED]> wrote in message
news:12784@palm-dev-forum...
>
> Thomas Ward <[EMAIL PROTECTED]> wrote:
> > StrPrintF(display_string, "%s:%c:%s", "str1", 'R', "str");
>
> fails, but
>
> > char c = 'R';
> > StrPrintF(display_string, "%s:%c:%s", "str1", c, "str2");
>
> works.
>
> Heh. I was wondering how long it would be before somebody noticed
> this one :-). Here's what's really going on.
>
> It all boils down to what type you want 'tFRM' to have. In Standard
> C, all char constants -- like both 'R' and 'tFRM' -- have type *int*.
> In the Palm OS ABI, int is only 16 bits, and that's not enough to
> represent 32 bit things like creator ids and resource types and so on.
>
> (The obvious answer is not to try to use char constants for these things,
> but it's too late for that. And before anyone claims that multichar
> char constants are implementation-defined and we can do what we like,
> note that their *values* are implementation-defined, but their *type*
> is required to be int.)
>
> Neither CW nor m68k-palmos-gcc implements Standard C in this regard.
>
> CW hacks it so that 'a' and 'ab' are of type int (16 bits, or 32 bits
> if 4 byte ints is turned on) while 'abc' and 'abcd' are of type long
> (32 bits). m68k-palmos-gcc hacks it so that all four are of type
> long (32 bits). This is a Palm OS-specific hack to GCC -- stock GCC
> follows the Standard.
>
> On the face of it, it's hard to say which one of these behaviours is
> more broken. It's probably fair to say that the CW behaviour is more
> convenient -- although possibly more confusing if you do run into
> problems.
>
> The situation is a little different in C++. In Standard C++, char
> literals like 'a' have type *char*, while multichar ones like 'tFRM'
> have type *int*. In CW C++, 'a' is char (8 bits), 'ab' is int (16 bits),
> and 'abc' and 'abcd' are long (32 bits). In m68k-palmos-g++, 'a' is char
> (8 bits) and the rest are all long (32 bits).
>
> (This means that Thomas's first example would work fine in C++, both
> in CW C++ and m68k-palmos-g++.)
>
> Amusingly enough, if you used 32 bit ints ("4 byte ints" in CW or
> "-mnoshort" in GCC), the CW hack and the GCC hack would produce the
> same results in all cases (both C and C++), and would be in accordance
> with the Standards. But doing that would lead to problems in itself --
> see http://www.escribe.com/computing/pcpqa/m10208.html .
>
> I think the progression of types in C++ motivates the CW behaviour,
> and fixing m68k-palmos-gcc to agree with this has been on my list for
> a while. It hasn't been done yet because I am interested to see whether
> Apple have already run in to this issue.
>
> Thomas has stumbled on to one of the very few ways to actually detect
> the difference. I can only think of two ways in C and three in C++.
> (Anyone? :-))
>
> Note that all this only applies to unadorned char constants/literals.
> If you have an explicit char variable like the second example above,
> or if you explicitly cast to char -- (char)'R' -- or int, the expression
> will have the type which %c is expecting (*) and everything will be fine.
>
> John
>
> (* which isn't char, btw. Consequently, answers like
>
> [Roger Chaplin]
> > When the compiler sees the literal 'R', it creates an int having the
> > value 82. You've told StrPrintF to expect a char at that place in the
> > argument list. That's why you don't get the error if you use
> > char c = 'R';
>
> are, I fear, quite wrong. C's calling conventions specifically cater for
> alignment issues like this. See
http://www.eskimo.com/~scs/C-faq/q15.10.html )
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
