RE: [Re: RPGILE V4.3 Gotcha]

You're right, what I was trying to say is that C doesn't  care about the
overflow in the signed (or unsigned) integer.  If you overflow a signed
integer you'll most likely get a negative, overflow an unsigned integer
you'll probably get something smaller than you expected.

There's also the thing with floating point calculations that should result
in zero, but that's just a formatting issue. <g>
> -----Original Message-----
> From: Jim Langston [mailto:jlangston@conexfreight.com]
> Sent: Friday, October 08, 1999 3:05 PM
> To: RPG400-L@midrange.com
> Subject: Re: [Re: RPGILE V4.3 Gotcha]
> 
> 
> Like I was saying, 65100 stored in a SIGNED integer is -436.  
> Unsigned it would
> be 65100.
> 
> Regards,
> 
> Jim Langston
> 
> Joel Fritz wrote:
> 
> > 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
> > +---
> 
> +---
> | 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
+---