🚀 go-pugleaf

In article <3A0F6C13.C8BFF209@gorge.net>, brunk@gorge.net wrote:

> MWRon wrote:
> > 
> > In article <rbarris-9F1405.11512510112000@news.intelenet.net>, Rob 
> > Barris
> > <rbarris@quicksilver.com> wrote:
> > 
> > >   I mailed this one into Metrowerks support but haven't seen a real
> > >response yet.  Wonder what all you readers think about it.  This
> > >actually caused a bug on some code I was moving from Pro5 to Pro6 on
> > >Windows.
> > 
> > This seems to have something to do with chars,  I've diiscovered if you
> > turn on the use unsigned char  it will work for you.  That is probably
> > better than redoing your entire code until it is fixed.
> 
> This is good advice. 
> 
> The compiler is free to treat type char as either signed or unsigned.
> It's up to the programmer to use type signed char or unsigned char
> explicitly if that is really what is desired. As long as the OP's code
> was written with these rules in mind, telling the compiler to treat type
> char as unsigned should work around the compiler bug.

   I will have to code it up at work tomorrow and check, but now I 
wonder about this case:

#define kLimit 256
void funny( char x )
{
   if (x < kLimit)
   {
    printf("less");
   }
   else
   {
    printf("not less");
   }
}

main()
{
   funny(1);
}

   In short I am wondering, once signed versus unsigned is taken out of 
the equation, if it gets it right or not.  If it follows past behavior, 
it will cast the 256 down to 8 bits and turn it into a zero.  Sign not 
relevant here.

   Any C experts want to come down on the above example as poor code?

   Shouldn't I be able to compare a char with an int ?

Rob