|
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 +---
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.