3

I'm getting this error

System.OverflowException: Arithmetic operation resulted in an overflow.

when i ran my application on Windows Server 2008 R2 Standard compiled in .Net 2.0 or greater (.Net 4.0). From what i know, C# should ignore Arithmetic overflow if it is compiled without /checked parameter. In my app there are many places where overflow can happened, so i need to ignore it.

I traced one example:

using System;

namespace ArithmeticOverflow
{
    class Program
    {
        static void Main( string[] args )
        {
            GetTypeID( typeof( Program ) );
        }

        public static int GetTypeID( Type type )
        {
            return type.GetHashCode() ^ type.FullName.GetHashCode() ^ type.TypeHandle.Value.ToInt32();
        }
    }
}

Compiled with .net 2.0:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe /out:test.exe Program.cs

When i run this program on my desktop computer, everything go fine. But when i run it on server, it crash. I cannot find the problem.

If i compile it with .net 1.1:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\csc.exe /out:test.exe Program.cs

It is alright on desktop PC and on server too. So where is the problem ? Please help.

UPDATE

Solved by using /platform:anycpu32bitpreferred

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\csc.exe /unsafe /platform:anycpu32bitpreferred /out:test.exe Program.cs
user1576055
  • 567
  • 1
  • 4
  • 16

1 Answers1

3

I suspect you'll find the problem is that with .NET 1.1 you're running the x86 CLR in both cases, whereas with .NET 2.0 you're probably running with x86 on your desktop an x64 on your server.

IntPtr.ToInt32 is documented to throw OverflowException when:

On a 64-bit platform, the value of this instance is too large or too small to represent as a 32-bit signed integer.

Basically, it's dangerous to call that. Why not just use IntPtr.GetHashCode()? (It's not clear what exactly you're trying to achieve with this code anyway, to be honest.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • My desktop PC is Windows 7 Ultimate 64 bit. So it should crash too, am i right ? My app is modified RunUO 1.1 and there are many places where overflow can occur, so it will be very time consuming to fix it. – user1576055 Jan 21 '15 at 21:24
  • @user1576055: You'd have to print out `System.Is64BitProcess` or something similar to verify which CLR is being used. But just because you've got a bug in multiple places doesn't make it any less of a bug. Note that this isn't about *arithmetic* overflow - it's about this one specific method. If you're calling this one method (`Int64.ToInt32`) in lots of places in the same kind of way, you might want to consider refactoring them all to one place first... – Jon Skeet Jan 21 '15 at 21:26
  • You are right, thank you. On my desktop PC Environment.Is64BitProcess is false, but on server it is true. If the problem is only in ToInt32() method, i will try to fix it, it shouldn't be too hard. Thank you very much. – user1576055 Jan 21 '15 at 21:36
  • @JonSkeet I know it's bit off topic. There is already SO question: [why dont languages raise errors on integer overflow by default](https://stackoverflow.com/questions/103654/why-dont-languages-raise-errors-on-integer-overflow-by-default). I don't see any comments from any of experts on this. All answers kind of boils down to - "yeah, it is not enable by default because of performance cost..but checked behavior is something which user would expect almost most of the times" Having said that, so one should start with that or no considering performance implications ? – rahulaga-msft Nov 08 '18 at 07:32
  • @RahulAgarwal: As you say, that's not really on topic - comments on Stack Overflow aren't intended for discussion like this. – Jon Skeet Nov 08 '18 at 09:13