🚀 go-pugleaf

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.

Rob also cc'd me on that report.  Not being a compiler guy I simply
forwarded it on to the x86 compiler team.  This afternoon I got a reply
that it looked like a bug to them as well.

-Howard

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.

Ron

-- 
CodeWarrior PersonalJava Edtion
The speed, integration, and flexibility of the product are truly impressive.
Java Report Online
http://www.javareport.com/html/from_pages/product_review.cfm?articleID=1616

Metrowerks  "Software Starts Here"   MWRon@metrowerks.com

In article <1ejy14n.67hdw91ccxccaN%remove.fte@writeme.com>, 
remove.fte@writeme.com (Fabrice Truillot) wrote:

> Rob Barris <rbarris@quicksilver.com> wrote:
> 
> > > Built under CW6 on Windows as a console app, I get the output
> > > 
> > > not less
> > > not less
> > > 
> > > Built under CW6 on MacOS/PPC as a console app, I get this:
> > > 
> > > less
> > > less
> > > 
> > > Who's in the wrong here?
> 
> Try this :
> 
> #include <limits>
> 
> /* some other #include needed */
> 
> int main ()
> {
>     if (numeric_limits<char>::is_signed)
>     {
>         std::cout << "char is signed -> -128 ... + 127"
>                   << std::endl;
>     }
>     else
>     {
>         std::cout << "char is'nt signed -> 0 ... 255"
>                   << std::endl;
>     }
> }
> 


   I'm at home and don't have the Windows compiler handy - but no matter 
what the above reports, the 'chars' in question only assume values of 0 
and 1, in the example posted.  Where it gets into trouble is in 
comparison of such a variable to a constant (not another char, just the 
number 200).

   Clearly either the 'char' should be promoted to int, or the 200 gets 
demoted to char (which would cause the problem I saw on CW/Win) before 
the comparison can take place.  I had always thought that in a case like 
this, the smaller type would get promoted to the larger type and avoid 
this problem.

Rob

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.

Regards
-- 
Matt Brunk

In article <rbarris-484498.22494212112000@news.irvn1.occa.home.com>, 
Rob Barris <rbarris@quicksilver.com> wrote:

> 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);
> }

   More info.

   The above code prints "not less" if kLimit is anything from 129 to 
255 inclusive.  Once I change kLimit to 256 or higher it prints "less". 
(CW6, Windows x86 compiler).

   I did another version using 'short' and a kLimit constant of 32769, 
no problems there.  It seems to specifically affect signed chars being 
compared against numeric constants between >=129 and <=255.

Rob

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

In article <rbarris-6FA5D9.13581513112000@news.intelenet.net>, Rob Barris
<rbarris@quicksilver.com> wrote:

>   The above code prints "not less" if kLimit is anything from 129 to 
>255 inclusive.  Once I change kLimit to 256 or higher it prints "less". 
>(CW6, Windows x86 compiler).

The problem was that the x86 compiler was trying to get around this
implicit promotion to int by restoring the comparison to compare chars,
but it considered 128..255 to be unsigned chars.

This will be fixed in the next release.  Metrowerks apologizes for this
inconvenience.
Ron

-- 
CodeWarrior PersonalJava Edtion
The speed, integration, and flexibility of the product are truly impressive.
Java Report Online
http://www.javareport.com/html/from_pages/product_review.cfm?articleID=1616

Metrowerks  "Software Starts Here"   MWRon@metrowerks.com