Do the C# and Java specifications spell out the same behavior on signed integer overflow?

Question

In C and C++, the behavior of signed integer overflow or underflow is undefined.

In Java and C# (unchecked contexts), the behavior seems to be defined to an extent.

---

From the Java specification, we have:

The integer operators do not indicate overflow or underflow in any way.

And:

The Java programming language uses two's-complement representation for integers [...]

---

From the C# specification, we have:

[...] In an unchecked context, overflows are ignored and any high-order bits that do not fit in the destination type are discarded.

---

By testing out both, I got the expected wrap-around result. Judging from the wording of the specs, I get the feeling that in Java the result is portable (because the language requires a 2's complement representation) while C# may or may not have that result (as it doesn't seem to specify a representation - only that the higher order bits are discarded).

So, do both language specifications guarantee the same behavior on all platforms (just with different wording)? Or do they simply happen to be the same with each other in my test case (on a x86 and under Sun's JRE and Microsoft's .NET), but could theoretically differ on other architectures or implementations?

Answer 1

In Java the portability is ensured by Java Language Specification which states all the rules around primitive type intbeing signed 32bit 2's complement integer. Then the standard library itself implements Integer class which wraps int value and adds few convenience methods, but is essentially the same as far as the range and overflow are concerned.

In .NET there are primitive types defined by the CLR too and these too are wrapped by different classes and aliases depending on the language. See Common Language Specification - esp. Common Type Systtem.

So to answer your question, in Java the code is portable as ensured by Language Spec and JVM implementation. In .NET (since CLR runs also C++ code which in turn can be not CLS compliant operating at closer to the iron level) you have to make sure that your code is portable by making it CLS Compliant. Good news is that using int and/or System.Int32 makes you CLS compliant, ergo portable.