|
Akram El Assas wrote: Do serial downvoters still exist on CodeProject? Probably got a whole new generation of them. We also still got stalkers too and people that will argue over anything. So, welcome to the Internet.
Jeremy Falcon
|
|
|
|
|
|
Yea seriously. They exist all over. I posted a few answers on stackoverflow a while back -- one jamoke copied my answer and reformatted it, and then had the balls to downvote my answer. The jackweed had a gozzillian StackOverFlow points too. I had to argue with the site to get me back into the black, just so i could use the site.
~d~
|
|
|
|
|
may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
|
|
|
|
|
I code in C, so I'm safe.
Jeremy Falcon
|
|
|
|
|
What could go wrong...right?
I don't think before I open my mouth, I like to be as surprised a everyone else.
PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com
Latest Article: SimpleWizardUpdate
|
|
|
|
|
The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed. You can also, if you're adding two 32-bit numbers together, cast them both to 64-bit, then add them and check if the resulting 64-bit value is greater than INT32_MAX.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Many moons ago, I was called in as consultant for a small business using Cobol
and random access files for recording inventory transactions.
Their main database file had been corrupted with new transactions
overwriting existing transactions.
I suspected integer oveflow.
The field in the header record for the file was used to store the
next free location. It was 16 bits so once they reached 65536
transactions the next free location was previously used.
The Cobol number field was always positive so the roll over just went backwards.
They were very surprised that 65536 transactions had occured.
The coding fix was easy. I had to calculate the corrupted locations and
restore the data from backups. Because I was still in Grad school,
and the owner provided me extra pay for less hours
so I could finish.
True story.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Quote: The usual way is after adding two positive numbers together, check if the result is negative. If it is, you've overflowed.
This doesn't work, because overflowing is undefined behaviour and the compiler is allowed to remove the check (i.e. it will never overflow).
See this short snippet[^]
The compiler completely removes the "overflow" path, so the check you propose *always* prints "Not overflowed".
|
|
|
|
|
As mentioned above, specifically undefined behavior might turn out in such a way that the "signed"ness does not necessarily flip as you would expect. Having said that, I don't know of a CPU/compiler that doesn't simply let the integers wrap around because that is still the easiest to implement.
I was almost trying to propose some right-shift logic trick to check, but, the right-shift is, in fact, undefined for signed integers as well and may give invalid results.
In assembly it's plain simple, you typically check the carry or overflow flag for unsigned or signed integers, respectively.
Finally, a watertight solution would be to cut every integer in two halves using masks and shifts, then craft your own carry- and overflow logic. I'm too lazy to work it out in detail but I'm positive that all the information you need to detect overflow is in the high bits of the upper sum. Something like, upper half, or upper half + 1 bits must turn out equal, and if not, there is overflow.
|
|
|
|
|
|
I only ever use small numbers.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It's not a hardware operation?
|
|
|
|
|
Like OG, I don't use big integers. If I did need big integers, I would probably use a library that provided arbitrarily large numbers - certainly slower than CPU math, but at least 90% of the time acceptable.
If you're in that gray area where you might get integer overflow, then you might use some of the techniques suggested on this SO page : https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-integer-overflow
Keep Calm and Carry On
|
|
|
|
|
Requirements, architecture and design.
So no detection but prevention. The business domain can insure that large sets cannot exist.
Then from that there might be limited sets with the potential. So one must analyze the problem to insure the following.
1. Can it occur at all?
2. What is the timeline for when it can occur? 1 year? 10 years? 50 years?
Myself I do not even attempt to program for long term problems which do not exist now. History does not suggest that doing that leads to better solutions - just ones that are more complex and harder to maintain.
If I find that it can occur now then I use a solution that allows for that actually handles large numbers. There are multiple libraries that provide large number handling.
|
|
|
|
|
Not here you can't.
|
|
|
|
|
Q/A would be a more appropriate forum
|
|
|
|
|
I have to be ill or something like that...
I agree with you
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hi Nelek
Yes, you're right, somehow something isn't right anymore, it's changed.
This is the second time you agree with me. And this after years of heated discussions
I guess it's because I've finally grown up
|
|
|
|
|
0x01AA wrote: I guess it's because I've finally grown up I would like to think than I have got younger...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
No chance for us all to turn back the clock
|
|
|
|
|
Quote: may i inquire how C++ integer arithmetic is performed in your code so as to prevent / detect / report overflow ?
Determining overflow is not possible with signed integers (compiler is free to remove the check on signed integers, but has to keep the check for unsigned integers) so I try to use unsigned over signed wherever possible, and then I can check rollover using less-than/greater-than zero for overflow/underflow respectively.
When I am forced to use signed (to interface to existing code), I use a larger integer than the interface specifies: use int16_t for 8 bit ints, int32_t for 16 bit ints, int64_t for 32 bit ints. For an interface that needs 64 bit ints I use the rollover/rollunder zero (using less-than and greater-than) after casting the signed 64 bit value to an unsigned 64 bit value.
Under no circumstance is it safe to use plain `int` portably. All usage of plain `int` depends on the platform (hardware + compiler + OS combination), so you cannot write code that works now and in the future, you can only use the plain `int` type for code on a particular platform at a particular point in time - future versions of your platform have have a different sized `int`.
|
|
|
|
|
Sorry for inadvertent click on inappropriate content
Joan F Silverston
jsilverston@cox.net
nhswinc.com
|
|
|
|
|
An ounce of prevention is worth a pound of cure.
Take either addend and subtract it from the maximum. If the result is smaller than the other addend, you will overflow.
If Max - A < B,
then A + B > Max // OVERFLOW
|
|
|
|
|
Whether an ounce is more than a pound depends on foreign imperial units, and scales that might overflow.
Having said that, the method is properly defined in C(++) for unsigned all integers, using each their respective maximums, and easier than what I proposed.
|
|
|
|