|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.