Talk:Integer overflow

[Untitled]

Integer arithmetics are frequently used in computer programs on all types of systems, since floating-point operations may incur higher overhead (depending on processor capabilities).

Floating-point operations may or may not actually be more expensive than integer arithmetic on given hardware. I think there are much better reasons to use integers instead of floats: integers are exact and give you more precision than floats of the same size. For example, in a 32-bit integer, you get 32 bits of precision, whereas an IEEE single precision float, which also takes 32 bits, provides only 24 bits of precision (23 bits mantissa, and the sign bit). When the numbers you're trying to represent are integers (or even rationals with a common denominator), you're therefore better off using ints.

Inglorion 09:27, 19 August 2006 (UTC)

Merge with arithmetic overflow

Integer overflow is a special case of arithmetic overflow. I don't see the need for two articles. Derek farn 08:54, 10 October 2006 (UTC)

I think this makes sense as two different articles. Integer overflow is of particular interest in computer security and is reference from the computer security page. The content on this article is currently underdeveloped and could be significantly expanded. Rcseacord 18:10, 12 December 2006 (UTC)

But, currently, the arithmetic overflow page adds no significant value, and only confuses because there is no obvious difference between integer overflow and arithmetic overflow. In fact, the first line of 'integer overflow' says "an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is too large to be represented...", which is exactly the definition of arithmetic overflow. Until there is something in the two articles that shows a difference between these two terms, they really should be merged. 141.166.41.125 (talk) 21:05, 6 September 2015 (UTC)

Note to self. -- C. A. Russell (talk) 19:08, 9 May 2009 (UTC)

Wrap around, Signed/Unsigned, mixed message

From the article:

Since an arithmetic operation may produce a result larger than the maximum representable value, a potential error condition may result. In the C programming language, signed integer overflow causes undefined behavior, while unsigned integer overflow causes the number to be reduced modulo a power of two, meaning that unsigned integers "wrap around" on overflow. This "wrap around" is the cause of the famous "Split Screen" in Pac-Man.

A "wrap around" corresponds to the fact, that e.g. if the addition of two positive integers produces an overflow, it may result in a negative number. In counting, one just starts over again from the bottom.

Example: 16 bit signed integer: 30000 + 30000 = −5536.

The example given here of a negative number resulting from addition is an example of a signed integer overflow, but its usage immediately after the statement about C programming behavior is contradictory. I don't know enough about C programming to know whether the statement that "signed overflow produces undefined behavior, while unsigned overflow produces wrap around" is accurate or transposed. If it is accurate, the example should be changed to, perhaps, 35000 + 35000 = 4464; otherwise, the words "signed" and "unsigned" words should be swapped to be accurate in the preceding statement. 199.2.205.141 (talk) 14:15, 29 October 2013 (UTC)

Signed overflow is undefined in C. I changed the example to prevent confusion. Hiiiiiiiiiiiiiiiiiiiii (talk) 01:52, 13 January 2014 (UTC)

Merger proposal

I propose that Arithmetic overflow be merged into Integer overflow. The arithmetic overflow article is short and underdeveloped, and duplicates the material in integer overflow. Ads they currently stand, there is no apparent difference in definition between the two terms. 141.166.41.125 (talk) 21:05, 6 September 2015 (UTC)

I agree Mchcopl (talk) 18:42, 12 April 2016 (UTC)!

I agree. This needs to be acted on. 98.122.177.25 (talk) 20:14, 12 July 2016 (UTC)

Ouch! It should have been the other way around. Integer overflow is a special case of arithmetic overflow, which can also include float overflow (too large integer exponent, which again is a type of integer overflow, but is (or may be) handled differently for the exponents of floats (i.e. by assigning the special +Infinity and -Infinity values)).37.44.138.159 (talk) 07:18, 25 August 2019 (UTC)

Ambiguity Regarding underflow

The definition of integer underflow is incorrect. Integer overflow is the blanket term for where a value exceeds the range of an integer. When the maximum value is exceeded, this is positive overflow. When the minimum value is exceeded, this is negative overflow -- not underflow!

Integer underflow is a less remarkable example of information loss, where precision is lost due to an arithmetic operation such as integer division or bitwise right-shift, or due to a conversion from a type that can represent fractional values, e.g. floating-point. For example, where 3 / 2 = 1, we are seeing integer underflow.

The references to integer underflow are misleading. There will always be more examples of the misuse of the term integer underflow than examples of its correct use, because the proportion of material concerned with integer overflow far exceeds that concerned with integer underflow. Thus a picture is painted of a general consensus around the incorrect definition. Of the five citations, the first is an article CWE-191 which gets the definition of underflow wrong. The second has only one reference which is a broken link. The third has a mistake by its own definition (-1 is not a smaller absolute value than 0). The fourth, again, is using the wrong definition of integer underflow. The fifth begins by talking about buffer underflow and then continues the semantics into a section on integers.

The preceding wikipedia article [1] gets the definition of integer overflow right and even describes the example from the third underflow article as integer overflow. (But then it scores an own goal by saying this is integer wraparound. Ouch!)

Some of these citations are great examples of the ambiguity and require only minor clean-up. However the conclusion the draw is wrong. In particular, the following sentence is factually wrong and should be amended from

   When the term integer underflow is used, it means the ideal result was closer to minus infinity than the output type's representable value closest to minus infinity.

to:

   When the term integer underflow is used, it is often taken to mean the ideal result was closer to minus infinity than the output type's representable value closest to minus infinity.  — Preceding unsigned comment added by 95.44.211.219 (talk) 07:48, 1 September 2019 (UTC) 

Example: accession numbers

At [2]:

"Due to the continued growth of GenBank, NCBI will soon begin assigning GIs exceeding the signed 32-bit threshold of 2,147,483,647 for those remaining sequence types that still receive these identifiers. The exact date that the 32-bit threshold will be crossed depends on submission volume and is projected for late 2021."

This can be another example?

Proposal: I feel that there should be a more generalised Wikipedia article grouping topics that include Year 2000 problem, IPv4 address exhaustion and Integer overflow. These all relate to the same fundamental idea: problems (often unforeseen or ignored) arising from use of integer types with a maximum value that can eventually be exceeded.

—DIV (1.145.43.213 (talk) 06:48, 5 September 2021 (UTC))

Minecraft

It should be using Minecraft: Java Edition and Minecraft: Bedrock edition instead of "Windows 10 Edition"/"Pocket Edition"/"Minecraft". Bedrock edition also no longer has the far lands, and they were always different on bedrock. Eteled286 (talk) 23:59, 28 September 2022 (UTC)

unsigned integers

The article says that integer overflow does not occur for unsigned integers in the C11 standard. This is true, but slightly misleading as readers will think it is a C11 innovation. Actually the same thing was true in the ANSI/C89 standard (3.1.2.5) and the C99 standard (6.2.5). Apart from one word that seems redundant, both those standards have the same sentence as appears in C11. Zero^talk 04:28, 29 January 2023 (UTC)

Explanation for removal

I am removing this:

Caution should be shown towards the latter choice [testing for overflow after the operation]. Firstly, since it may not be a reliable detection method (for example, an addition may not necessarily wrap to a lower value). Secondly, because the occurrence of overflow itself may in some cases be undefined behavior. In the C language, overflow of unsigned integers results in wrapping, but overflow of signed integers is undefined behavior. Consequently, a C compiler is free to assume that the programmer has ensured that signed overflow cannot possibly occur and thus its optimiser may silently ignore any attempt to detect overflow in the result subsequent to the calculation being performed without giving the programmer any warning that this has been done. It is thus advisable to always implement checks before calculations, not after them.

The wiki-reason for removal is that it is unsourced. The real-life reason for removal is that it is nonsense. A C compiler is not entitled to read the programmer's mind on whether a bit of code is intended for overflow detection, and not entitled to assume that the programmer has taken precautions to avoid overflow. The implementation-defined nature of integer overflow means that the result of the operation is not specified in the standard, not that there is no result or that the compiler is allowed to assume the result is different from what it might actually be. For example, if the programmer writes, given x,y known to be positive, "z = x + y; if (z < 0) something;", the compiler is not allowed to generate code that might make z negative without executing something. However, the compiler is allowed to generate code that will set z to INT_MAX in the event of overflow, and then optimise out the test because it knows that z will always be positive. That's what "implementation-defined" means.

Another problem with the text is the incorrect before/after dichotomy. Suppose again that x,y are known positive. Compare these: "z = x + y; if (z < 0) something;" and "if (y > INT_MAX - x) something; z = x + y". If the compiler was permitted to assume overflow is not going to occur, both the before and after tests are available for optimising out. In principle, it is impossible to test for a condition that a super-smart compiler assumes does not exist. In actuality, both examples are valid though the second one only tests for overflow in the (overwhelmingly most common) case that the implementation-defined result of overflow is silent wrap-around.

Repeating myself a bit, "implementation-defined" means "the implementation has decided what the result will be". It does not ever mean "the implementation can make assumptions about the wishes of the programmer". If the implementation has decided that the result of integer overflow is silent wrap-around, then the compiler must generate code that is correct for silent wrap-around. It can't generate wrap-around code and then assume there was no wrap-around. Anyway, the most important reason for signed integer overflow being implementation-defined (and a good reason for testing before the operation for maximum portability) is that an implementation is allowed to generate a trap condition. Zero^talk 03:06, 12 September 2023 (UTC)

I might agree that the previous one isn't perfect, but recent discussions of C compilers indicate that it is needed, in some form or other. c optimizers have been doing things that I wouldn't suggest for some time. I disagree with this one, too, but it seems that they are doing it. Gah4 (talk) 05:11, 12 September 2023 (UTC)

Sorry, I can't understand your comment. What exactly are compilers doing, and what evidence can you offer? Zero^talk 12:58, 12 September 2023 (UTC)

Incidentally, I know of some things that look somewhat similar but are actually not. For example, "if (x + 2 > x) something" can be optimized to "something". It is valid because if no overflow occurs then the test is true arithmetically, and if there is overflow the result of the test is up to the implementation so treating it as true is allowed. A number of such gotchas are known. My example "z = x + y; if (z < 0) something" is not like that. Although the result of "z = x + y" is implementation-defined if it overflows, the meaning of "if (z < 0) something" is perfectly well defined. If execution flow reaches the statement "if (z < 0) something" with z < 0 but something is not evaluated, that's a bug. Zero^talk 13:53, 12 September 2023 (UTC)

I haven't followed it exactly, but I am pretty sure that there are plenty of sources. There is a lot of discussion, especially as programs fail. C has always had overflow undefined, as different processors do different things. But many people know what the common processors do, and assume that. Now they get surprised. The (x+2 > x) is the easy case, but there are many that are harder to see, and that compiler optimizers seem to find. Gah4 (talk) 20:26, 12 September 2023 (UTC)

Integer Underflow

This page had a similar passage trying to prove Integer Underflow with the same bogus sources as Arithmetic Underflow's page. In Arithmetric Underflow's Talk I have posted information discrediting the sources provided.

https://en.m.wikipedia.org/wiki/Talk:Arithmetic_underflow

I am under the belief these sections were provided by a biased individual, not formally educated in Computer Science, trying to prove a falsehood. The mere existence of a term in blogs, bug reports, section titles and circular reference should not be enough to prop a term into existence. Integer Underflow is not a quality term and is formed from a basic misunderstanding of what Integer Overflow is.

In Arithmetric Underflow, I removed the passage as I easily discredited the sources. Arithmetic underflow is more focused on floating point operations. Here I left it in place as there was an ambiguity section. I felt adding proper disqualification of the sources made the most sense. 24.112.251.203 (talk) 08:21, 18 June 2025 (UTC)

Multiple problems in new text

There are multiple problems in the new version. Some highlights that don't include many examples of bad writing:

• "The most common implementation of integers in modern computers are two's complement" — Bad grammar, plus this is only for signed integers.
• "Unfortunately, for most architectures the ALU doesn't know the binary representation is signed." — This is nonsense. What does it mean for the ALU to not know something? It knows the bit pattern of memory and it knows how to execute machine instructions. The closest relevance is that there is usually only one machine instruction for integer addition, and similarly subtraction. However, for multiplication, division and many comparisons, there are separate signed and unsigned instructions. What should be said is that it is the programmer, via the program, who gives interpretations to bit patterns in memory. The hardware just obeys the interpretation given to it by the program by virtue of the choice of instructions that the program provides.
• "Most ALUs perform operations on unsigned (positive) binary numbers. These ALUs do not have any capability of dealing with signed (positive and negative) numbers." — The examples of multiplication, division and comparison show this is not true. Even for the case of addition, although there is usually only one instruction, processors like Intel and ARM have flags that indicate signed overflow and flags that indicate unsigned overflow. Both are set or cleared and the program chooses which, if any, to query. In all cases, the computer knows perfectly well how to handle signed or unsigned integers.
• "When an operation occurs that results in a carry past the 31-bits allocated for the number, the sign bit is overwritten." — Wrong. The addition (-2)+(-2)=(-4) causes overflow into the sign bit, but it isn't signed overflow. The carry-wise description of signed overflow is that the carry into the sign bit differs from the carry out of the sign bit.
• "The ALU doesn't know it did anything wrong." — In 2025, computers still don't have moral sensibility (but wait another decade).
• "Using integers of the same size as the ALU's register width will have the best performance in most applications. ..." — This paragraph is not about the topic of the page and should be removed.
• "Integer Underflow is an improper term used to signify the negative side of overflow. This terminology confuses the prefix "over" in overflow to be related to the sign of the number." — "Improper" is not a defined concept, "negative side of overflow" has dubious meaning, and the second sentence is an unsourced opinion.
• The table — The footnotes have things like "most common", "typically", "default" without basis. Names like "uint32" are vendor-specific (for example they are not in the C or C++ standards). .NET naming conventions are not suitable for presentation as if they are more widely accepted. Integers with 128 bits are software provided, not hardware provided in any current cpus afaik.
• Probably more, but I'm running out of bullets. Zero^talk 03:15, 21 June 2025 (UTC)

If there are grammer issues that you can fix, just do it.

There are sections that a generalized verse specific, and it is unreasonable to detail every variant in summaries and origin sections. That is why the statements are not written as absolutes. I believe all of the updates are in context of the most used architectures. If anyone is using anything else, I believe they will understand that they are a possible outlier. To include all variants would be a form of over-complication and analysis paralysis.

Although, I appreciate the snarkiness about the ALU not having intelligence, in the next paragraph the ALU does know there is something incomplete thus returns a flag in those operations. The two paragraphs are supposed to highlight the difference in signed verse unsigned int operations. The ALU is stupid and I am trying to outline it's limitations. More information below following up on your math example.

I think you need to review how the ALU operates. Im not sure if you have ever taken a processor design course, or designed an ALU before, but I have after the x86 implementation the most common. For example, the add and subtract operation in the ALU is operating on the registers let's say 32-bits. The ALU doesnt have a Signed Int Add operator verse Unsigned Int Add it has a binary add. The program/implementation of the datatype places the constraints on the interpretation of the bits. Because the ALU only has binary add operation, the program/implementation has to handle the sign logic.

For your example the ALU can never do the (-4) + (-4) operation you gave as an example. (I'm going to use 8 bits for simplicity.) The ALU would do 1000 0100 + 1000 0100. The ALU doesn't know what the bits mean, it only know operations like add, subtract. To be clear: int8 1000 0100 is -4, and uint8 1000 0100 is 132. You tell the ALU to add reg containing 1000 0100 and it does that in binary. This binary is not signed at the ALU level. The construct of int8 or uint8 is at the program language level, not the ALU.

Let me quickly explain just the half adder to you. Although I am writing this as code, it is electrical silicone transistors, and-gates and or-gates at the ALU level.

HalfAdder(ref result, index, out carryOut) {

left = reg1[index], right = reg2[index];

result[index] = left | right;

carryOut = left & right;

}

For each bit index add legit is just 'and' and 'or' gate. So every index is added and then carries over to the next index. There is no magic here in understanding signs or integers or what the data means. The ALU does basic math operations on binary bits.

Also to clarify why I am being general here. I am aware instruction set extensions that do have separate registers for the sign, but that is not an appropriate topic for the summary or origin sections in my opinion.

About using integers of the same size for performance. This should be basic knowledge to anyone well educated in cs, but I wanted to highlight the purpose of not jumping into using longer ints for all operations. I felt that the reader could interpret that section as, oh to solve this issue I just need to make sure all my Integers are of infinite size. If you have a better idea on how to communicate that concept I'm all ears.

For Integer Underflow, it is hard to talk about ambiguous terminology, which is the section. It is almost impossible to find a quality citation for a made-up erroneous dubious term. This section is still improved over the last version that said, ~ Integer Underflow must be a thing because we found it in the following 6 citations. The citations of which included no definitions and blogs. I'd be more than happy to write a blog article so I can cite it, but what a petty thing to do.

.NET isn't a vender. It is a valid enough citation for a "typically and alias". This table was previous was a list without any citations listing the typical ranges. I added some alias to also highlight the difference between bytes, sbyte, int, and uint. The reason I chosen the .NET reference is because of the book Framework Design Guidelines ed.2 that outlines the debate of creating universal naming of said types. I find the request to refine an possible Alias because it isnt in c/c++ a bit narrow minded. Especially, when c/c++ is a much older language that only has a subset of what modern languages have. There are plenty of other citations out there like, https://users.cs.utah.edu/~germain/PPS/Topics/unsigned_integer.html but I felt that table was already heavy with citations. 24.112.251.203 (talk) 06:08, 21 June 2025 (UTC)