No Overflow Exception for Int in C#

No overflow exception for int in C#?

C# integer operations don’t throw exceptions upon overflow by default. You can achieve that via the project settings, or by making the calculation checked:

int result = checked(largeInt + otherLargeInt);

Now the operation will throw.

The opposite is unchecked, which makes any operation explicitly unchecked. Obviously, this only makes sense when you’ve got checked operations enabled in the project settings.

Overflow exception double into int

I'd say that depends entirely on your applications expectations.

If you know the double can be NaN or just larger than Int32.MaxValue and you like the function to continue with a specific result, you should write a check.

If an overflow is an actual exception that needs to be handled up-stack by some special logic, you should throw an exception.

No overflow error at compile time when int.MaxValue assigned to a variable

The compiler does not do in-depth analysis to detect any possible outcome where an integer variable could overflow. The first example is fairly obvious - the second needs to analyze two different lines of code to detect the overflow, which the compiler is not designed to do.

From the documentation for the checked keyword (emphasis added):

By default, an expression that contains only constant values causes a compiler error if the expression produces a value that is outside the range of the destination type. If the expression contains one or more non-constant values, the compiler does not detect the overflow.

Why don't I get an exception on integer (uint) under/overflow?

you have an arthmetic overflow just enable Buid-Advanced-Check for arithmetic... that and you will get this exception:

An unhandled exception of type 'System.OverflowException' occurred in
Additional information: Arithmetic operation resulted in an overflow.

System.OverflowException, and how to fix it

The important part is to pay attention to the exception message that the System.OverflowException produces, which is:

Value was either too large or too small for an Int32.

That gives you a big clue as to what the problem is.

Next, if you take a look at the value of textnumbers after the for loop has been completed, you'll see its value is 199201203205207. As Çöđěxěŕ mentioned, the maximum value a signed 32-bit integer can store is 2147483647, so the exception is telling you a 32-bit integer isn't large enough to store the value you want.

To fix this, you can use a 64-bit integer:

long num = Convert.ToInt64(textnumbers);

long represents a signed 64-bit integer, and can store values in the range -9223372036854775808 to 9223372036854775807, inclusive, which can comfortably store 199201203205207.

If ever you need to know the range of values a numeric type can represent, you can examine its MinValue and MaxValue properties (e.g. int.MinValue, or long.MaxValue).

One thing though: you should learn to work with the debugger, because it makes fixing this kind of problem by yourself trivial. It's worth investing that time so you can self-service problems like this, without relying on others.

Why does C# let me overflow without any error or warning when casting an Int64 to an Int32 and how does it do the cast?

By default, C# does not check for overflows when processing numbers. This includes things like wrapping from int.MaxValue to int.MinValue in addition and multiplication, and when you cast longs to ints. To control this, use the checked and unchecked keywords, or the /checked compiler option.

The value 1942903641 is the result when your long is truncated to an int. It comes from the 32 least significant bits of the long value, taken as a two's complement signed integer.

When using foreach, it's important to know that if you declare a type that doesn't match the type of the enumerable, it will treat it as if you casted to that type. foreach (int i in myCollection) compiles to something like int i = (int)myEnumerator.Current;, not int i = myEnumerator.Current;. You could use foreach (var i in myCollection) to avoid such mistakes in the future. var is recommended to use for the loop variable in for and foreach statements.

You can see the results of various things in the following example (hexadecimal output is used to show the truncation more clearly: they have the same ending digits, the int just lacks some of the more significant digits):

checked
{
    Int64 a = 12345678912345;
    Console.WriteLine(a.ToString("X"));
    Console.WriteLine((a % ((long)uint.MaxValue + 1L)).ToString("X"));
    try
    {
        Console.WriteLine(((int)a).ToString("X")); // throws exception
    }
    catch (Exception e)
    {
        Console.WriteLine("It threw! " + e.Message);
    }
}
unchecked
{
    Int64 a = 12345678912345;
    Console.WriteLine(a.ToString("X"));
    Console.WriteLine((a % (long)Math.Pow(2, 32)).ToString("X"));
    Console.WriteLine(((int)a).ToString("X"));
}

This outputs:

B3A73CE5B59
73CE5B59
It threw! Arithmetic operation resulted in an overflow.
B3A73CE5B59
73CE5B59
73CE5B59

.NET RT bug? Explicit conversion from float to int causes overflow, but no exception is thrown

You will need to manually enable 'Check for arithmetic overflow' from project properties -> build -> advanced

Best way to handle Integer overflow in C#?

I haven't needed to use this often, but you can use the checked keyword:

int x = foo();
int test = checked(x * common);

Will result in a runtime exception if overflows. From MSDN:

In a checked context, if an expression produces a value that is
outside the range of the destination type, the result depends on
whether the expression is constant or non-constant. Constant
expressions cause compile time errors, while non-constant expressions
are evaluated at run time and raise exceptions.

I should also point out that there is another C# keyword, unchecked, which of course does the opposite of checked and ignores overflows. You might wonder when you'd ever use unchecked since it appears to be the default behavior. Well, there is a C# compiler option that defines how expressions outside of checked and unchecked are handled: /checked. You can set it under the advanced build settings of your project.

If you have a lot of expressions that need to be checked, the simplest thing to do would actually be to set the /checked build option. Then any expression that overflows, unless wrapped in unchecked, would result in a runtime exception.

No overflow exception thrown for long/ulong SSE addition in C#?

Below is an implementation of ulong summation using SSE in C#. I'm posting it, since it's quite a bit shorter and easier to understand than the long summation.

private static decimal SumToDecimalSseFasterInner(this ulong[] arrayToSum, int l, int r)
{
    decimal overallSum = 0;
    var sumVector    = new Vector<ulong>();
    var newSumVector = new Vector<ulong>();
    var zeroVector   = new Vector<ulong>(0);
    int sseIndexEnd = l + ((r - l + 1) / Vector<ulong>.Count) * Vector<ulong>.Count;
    int i;

    for (i = l; i < sseIndexEnd; i += Vector<ulong>.Count)
    {
        var inVector = new Vector<ulong>(arrayToSum, i);
        newSumVector = sumVector + inVector;
        Vector<ulong> gteMask = Vector.GreaterThanOrEqual(newSumVector, sumVector);         // if true then 0xFFFFFFFFFFFFFFFFL else 0L at each element of the Vector<long>
        if (Vector.EqualsAny(gteMask, zeroVector))
        {
            for(int j = 0; j < Vector<ulong>.Count; j++)
            {
                if (gteMask[j] == 0)    // this particular sum overflowed, since sum decreased
                {
                    overallSum += sumVector[j];
                    overallSum += inVector[ j];
                }
            }
        }
        sumVector = Vector.ConditionalSelect(gteMask, newSumVector, zeroVector);
    }
    for (; i <= r; i++)
        overallSum += arrayToSum[i];
    for (i = 0; i < Vector<ulong>.Count; i++)
        overallSum += sumVector[i];
    return overallSum;
}

Both ulong[] and long[] summations using SSE and accumulating to Decimal, to produce a perfectly accurate result have been added to the HPCsharp nuget package that I maintain (open source). The version for long[] is in SumParallel.cs and is called SumToDecimalSseFasterInner().

It's pretty cool to be able to sum long[] or ulong[] arrays using SSE, handling arithmetic overflow in SSE, since the CPU doesn't produce overflow flags for SSE, and do it at SSE speeds, and multi-core!

Why doesn't this program overflow?

When you use constant values:

uint l = (uint)(int.MaxValue - int.MinValue);

The compiler knows exactly what you're trying to do because it knows the values, and it sees that the result of the subtraction cannot fit in an int, so it gives you the error.

When you use variables:

return (uint)(b - a);

The compiler has no idea at compile time what the values of the variables will be, so it doesn't complain.

Note that the overflow is in the int, not uint as you stated in your now-deleted answer. You may think that you are subtracting big value from small value, but you're not. The int.MinValue is actually negative (-2147483648) and subtracting it means you're actually adding it (2147483647 - (-2147483648)), so the result (4294967295) cannot fit in int, but it can fit in uint. So for example, this will compile and give the correct result 4294967295:

uint x = (uint)((long)int.MaxValue - int.MinValue);

Because now you're telling the compiler to store the result of the subtraction in long instead of int and that will work. Now print x to the console and notice that the result of the subtraction is 4294967295, not -1 as you're stating in your answer. If it was -1 like you said, then the code below should compile, but it doesn't because 4294967295 overflows the int:

int x = int.MaxValue - int.MinValue;

Edit There are more people who are struggling to understand the result, so here is even more explanation that I hope will help:

First of all, we all know that int.MaxValue is 2147483647 and int.MinValue is -2147483648. I hope that we also all agree on this simple math without having to prove it in a program:

2147483647 - (-2147483648) = 4294967295

So we should all agree that the math result is 4294967295, not -1. If somebody does not agree with that, please go back to school.

So why the result in the program is sometimes -1 which is confusing so many people?

OK, we all agree that an overflow occurs, so that's not the issue. Some people don't understand where the overflow is happening. It is not happening when casting to uint. Surely -1 will overflow uint, but the program is overflowing the int in the step before casting to uint. When an overflow occurs, the program behavior varies depending the on the execution context (checked or unchecked). In a checked context, an OverflowException is thrown, and nothing is executed afterwards, so the casting to uint is not executed. In an unchecked context, the most significant bits of the result are discarded and execution continues, so the casting to uint is then executed and another overflow occurs. Here is an MSDN article about how the integer overflows behave.

So let's see how we're getting -1:

First, in C#, when you subtract two integers, the result is an integer. Now if the result cannot fit in an integer, an overflow occurs. The tricky part is that in an unchecked context, the most significant bits of the result are discarded, like I mentioned above. In the question's scenario, that results in -1. Here are some examples that I hope will make this clear:

Console.WriteLine(unchecked(int.MaxValue)); //Result 2147483647
Console.WriteLine(unchecked(int.MinValue)); //Result -2147483648
Console.WriteLine(unchecked(int.MaxValue-int.MinValue)); //Result -1 overflow
Console.WriteLine(unchecked(2147483647-(-2147483648))); //Same as above
Console.WriteLine(unchecked(int.MaxValue+int.MinValue)); //Result -1 no overflow
Console.WriteLine(unchecked(2147483647+(-2147483648))); //Same as above
Console.WriteLine(unchecked(int.MaxValue+1)); //Result -2147483648 overflow
Console.WriteLine(unchecked(2147483647+1)); //Same as above
Console.WriteLine(unchecked(int.MaxValue-int.MaxValue)); //Result 0
Console.WriteLine(unchecked(2147483647-2147483647)); //Same as above
Console.WriteLine(unchecked(int.MaxValue+int.MaxValue)); //Result -2 overflow
Console.WriteLine(unchecked(2147483647+2147483647)); //Same as above

The results of these examples should be clear. I'm not doing any casting here to avoid the argument about where the overflow is happening, so it is clear that it is happening in the int. Every time an overflow happens, it is as if the first int is assigned the value of int.MinValue which is -2147483648 and then the second int is added/subtracted.

If you cast the first number to long, then the result will be long. Now no overflow will occur and you will get the same results as in math:

Console.WriteLine((long)int.MaxValue); //Result 2147483647
Console.WriteLine((long)int.MinValue); //Result -2147483648
Console.WriteLine((long)int.MaxValue-int.MinValue); //Result 4294967295
Console.WriteLine((long)2147483647-(-2147483648)); //Same as above
Console.WriteLine((long)int.MaxValue+int.MinValue); //Result -1
Console.WriteLine((long)2147483647+(-2147483648)); //Same as above
Console.WriteLine((long)int.MaxValue+1); //Result 2147483648
Console.WriteLine((long)2147483647+1); //Same as above
Console.WriteLine((long)int.MaxValue-int.MaxValue); //Result 0
Console.WriteLine((long)2147483647-2147483647); //Same as above
Console.WriteLine((long)int.MaxValue+int.MaxValue); //Result 4294967294
Console.WriteLine((long)2147483647+2147483647); //Same as above

And here is the evidence without using any addition/subtraction. Simply casting a value above the int.MaxValue causes an overflow which unchecked converts to int.MinValue. Any value greater than int.MaxValue + 1 will be added to int.MinValue:

Console.WriteLine(unchecked((int)2147483647)); //Result 2147483647
Console.WriteLine(unchecked((int)2147483648)); //Result -2147483648 overflow
Console.WriteLine(unchecked((int)2147483649)); //Result -2147483647 overflow
Console.WriteLine(unchecked((int)2147483649)); //Result -2147483647 overflow
Console.WriteLine(unchecked((int)2147483650)); //Result -2147483646 overflow
Console.WriteLine(unchecked((int)2147483651)); //Result -2147483645 overflow

The exact opposite happens when you overflow the int with values below int.MinValue:

Console.WriteLine(unchecked((int)-2147483648)); //Result -2147483648
Console.WriteLine(unchecked((int)-2147483649)); //Result 2147483647 overflow
Console.WriteLine(unchecked((int)-2147483650)); //Result 2147483646 overflow
Console.WriteLine(unchecked((int)-2147483651)); //Result 2147483645 overflow

This makes int work like an infinite rotating spinner. The two end are glued next to each other, so when you reach one end, you flip to the other one and continue 1 2 3 1 2 3 1 2 3.

---

Related Topics