Question

I inquired on VB.NET‘s erratic behavior of treating all numerics as signed types back in Stack Overflow question Unsigned left shift in VB.NET?, and from the accepted answer there, was able to get by. Per that answer:

Visual Basic Literals

Also keep in mind you can add literals to your code in VB.NET and explicitly state constants as unsigned.

So I tried this:

Friend Const POW_1_32 As UInt32 = 4294967296UI

And VB.NET throws an Overflow error in the IDE. Pulling out the integer overflow checks doesn’t seem to help — this appears to be a flaw in the IDE itself.

This, however, doesn’t generate an error:

Friend Const POW_1_32 As UInt64 = 4294967296UL

So this suggests to me that the IDE isn’t properly parsing the code and understanding the difference between Int32 and UInt32. Any suggested workarounds and/or possible clues on when Microsoft will make unsigned data types intrinsic to the framework instead of the hacks they currently are?

EDIT: Ignore me. All the answers are correct, I’m having an idiot moment this late at night. The value is too large for the UInt32 data type. ::facepalm::

Answer 1

There’s no insidious bug or hack at play here. The number you are trying to assign to a UInt32 type is simply larger than its maximum allowed value. Why jump to the conclusion that Microsoft screwed up?

The maximum value of the UInt32 type is 4,294,967,295. You’re trying to assign a value that is one greater than the max value (4,294,967,296). Thus, the compiler is correct in throwing an overflow error. This is the expected behavior.

Everything works out fine when you try to assign the same number to a UInt64, because its maximum value is much larger at 18,446,744,073,709,551,615—the value 4,294,967,296 is well within its range.