RE: [Re: RPGILE V4.3 Gotcha]

My recollection from turbo c++ back in 91 or so, that was the way integer
overflow worked.  I think unsigned integers just wrapped which is the
behavior you're seeing except it's going through the two's complement
translation into negative numbers.  It's actually a lot like RPG truncation
because the leftmost binary digit goes to the bit bucket.  
e.g. 1111 1111 1111 1111 + 0000 0000 0000 0001 = 0000 0000 0000 0000

My C teacher's favorite saying was "C doesn't care."  


> -----Original Message-----
> From: Jim Langston [mailto:jlangston@conexfreight.com]
> Sent: Friday, October 08, 1999 12:32 PM
> To: RPG400-L@midrange.com
> Subject: Re: [Re: RPGILE V4.3 Gotcha]
> 
> 
> You forgot something, the range of a short integer in C is 
> -32768 to 32767
> because of the sign bit.  When you assign the value 65100 to 
> the variable
> A it is taking the high bit (32768) and making it the sign bit.
> 
> Also, in Intel integers are stored in what is called "2's 
> compliment".  The bit's
> 
> are reversed and 1 is added (don't ask me why, it was 
> explained to me once
> but didn't make much sense).  The effect of this is: take 
> your number and
> calculate what it would be minus the high bit, 32768, and it 
> comes out to
> 32332.  32768 - 32332 is 436.  Plus the sign bit makes it 
> -436, which is your
> answer.
> 
> In C you can assign between characters, integers and hexadecimal with
> out any complaint from the compiler.  The compiler doesn't 
> care if you give
> it the hexadecimal format (0x1234 or whatever) or the decimal 
> format (65100)
> it happily goes along and does exactly what you told it, it 
> assigns the bit
> pattern
> you gave it to the variable.
> 
> To check this yourself, assign a value lower than 32767 to 
> the variable A, such
> as 32000, and by multiplying it by 100 it should overflow the 
> integer (making it
> 3200000) then divide by 100, and it would come back to 32000.
> 
> I am actually surpassed by this, however, as I would of 
> thought that you would of
> 
> gotten an over flow error, but I guess C is converting it to 
> a long in the math
> when
> it sees it has to, then type casting it back to a short to assign it.
> 
> Regards,
> 
> Jim Langston
> 
> Buck Calabro wrote:
> 
> > > >After 5 or 6 languages, I still usually check to make sure
> > >they are doing it the same way.  And so far I haven't run
> > >across any problems, not even with the MULT statement
> > >in RPG.
> >
> > Actually, RPG was always different from other languages 
> because of the fixed
> > size of the numbers.  We never much thought about it 
> because MULT and DIV
> > cannot produce intermediate results.  I believe that EVAL 
> works very much
> > the same as other languages.  Take this C code that I just 
> tried on the 400:
> >
> > #include <stdio.h>
> > void main () {
> >
> > short a;
> > short b;
> > long  c;
> >
> > a = 65100;
> > b = 100;
> > c = a * b / 100;
> > printf("result=%i\n", c);
> >
> > }
> >
> > Although "natural" arithmetic tells you that the result 
> should be 65100, the
> > result is actually -436.  I have no run-time error, nor do I have a
> > compile-time error warning me that I might lose precision.  
> I am certainly
> > not versed in too many languages, but it seems to me that 
> any language
> > allowing expressions will exhibit similar behaviour.
> >
> > Buck Calabro
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---