[windev] offtopic C cast

[Mark McGinty]

The underlying problem seems to be some sign bit extension and/or promotion
glitch, when resolving sub-expressions.  

Yeah, look at the resulting values in hex:

4294884256 = FFFEBBA0
900000     =    DBBA0

The expressions used to assign x8 and x9 cast the result of sub-expression,
not the operands within them. 

For x11, otoh, the constant 256 is forced to unsigned long, forcing
automatic type promotion of the other operands, and avoiding signed/unsigned
mismatch.

The end value of x10 was apparently not high enough to be subject to the
flaw.

The interesting thing to look at would be the value of (c1 * 256 + c2), with
and without the cast.


-Mark


Btw, I think few (if any) of us here would say that casting is categorically
horrible -- if it is, every SDK I've ever seen is replete with inherent
evil.  (I'm neither stating nor refuting that to be the case, I'm merely
saying that the presence of c-style typecasts within them is not the
deciding factor, because it's common to all of them.)




> -----Original Message-----
> From: windev-bounces at windev.org 
> [mailto:windev-bounces at windev.org] On Behalf Of Paul Stephenson
> Sent: Friday, January 23, 2009 5:15 AM
> To: 'Windev'
> Subject: [windev] offtopic C cast
> 
> Hello.
> 
> Apologies for the offtopic post but I was interested if any 
> of you clever guys out there had a view on what the compiler 
> might be doing here. I know the casting is horrible - I 
> didn't write it.
> 
> I am developing embedded code using an IAR toolset and after 
> upgrading to version 3.30A of the C compiler found the 
> following compiler bug! after reducing the code to the minimum.
> 
> unsigned char c1=0, c2=15;
> unsigned long x8  = 60000ul * ((unsigned long) (c1*256 + 
> c2)); // not work (= 4294884256) unsigned long x9  = 60000ul 
> * (unsigned long)((unsigned long) (c1*256 + c2)); // not work 
> (= 4294884256) unsigned long x10 = ((unsigned long) (c1*256 + 
> c2)); // ok (=15) unsigned long x11  = 60000ul * ((unsigned 
> long) (c1*256ul + c2)); // ok (=
> 900000)
> 
> --
> c1 and c2 defined as 16bit int also does not work
> 
> Thanks in advance.
> 
> 
> Paul
> _________________________
> 
> Paul Stephenson 
> 
> -- 
> Windev mailing list at Windev at windev.org
> 
> Lost your password?  Need to unsubscribe or change your 
> delivery options?  
> Go to http://lists.windev.org/mailman/listinfo/windev
> --
> Search the Windev Archives - www.windev.org
>