[windev] offtopic C cast

[Mark McGinty]

> -----Original Message-----
> From: Paul Stephenson [mailto:paul.a.stephenson at ntlworld.com] 
> Sent: Saturday, January 24, 2009 5:26 AM
> To: 'Windev'; Mark McGinty
> Subject: Re: [windev] offtopic C cast
> 
> Hi Mark,
> 
> Many thanks for the reply.
> 
> I had come to the same sort of conclusion from looking at the 
> hex but could not figure how it was occurring.
> The real puzzle being x10 as the expression evaluates 
> correctly with and without a cast, so what is going on when 
> combined with the 60000ul multiplication!

That's a very good question!  Are compiler optimizations of any sort
enabled?  Will it generate assembly code output?  (The latter might shed
some light on exactly how the type cast was implemented... Otoh it might
merely introduce more confusion -- for me personally, way too close to
call!)  :-)


-Mark





> Incidentally, to correct myself, I had not meant to imply 
> that all c-style casting is horrible but just its 
> poor/inconsistent use. I come from a C background and hence 
> use it extensively, on occasions incorrectly I am sure!
> 
> Anyway thanks again for the reply. I will be interested to 
> see what the IAR compiler folk have to say on the matter.
> 
> Cheers
> Paul
> 
> ----- Original Message -----
> From: "Mark McGinty" <mmcginty at dbunwired.com>
> To: "'Paul Stephenson'" <paul.a.stephenson at ntlworld.com>; "'Windev'" 
> <windev at windev.org>
> Sent: Saturday, January 24, 2009 8:14 AM
> Subject: RE: [windev] offtopic C cast
> 
> 
> > 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
> >>
> > 
> 
>