0x80000000 == 2147483648 in C# but not in VB.NET

Error processing SSI file

Answers

  1. Brian

    • 2020/3/6

    The VB version should be:

    &H80000000L=2147483648
    

    Without the 'long' specifier ('L'), VB will try to interpret &H8000000 as an integer. If you force it to consider this as a long type, then you'll get the same result. &H80000000UI will also work - actually this is the type (UInt32) that C# regards the literal as.

  2. Jeffery

    • 2020/4/16

    0x80000000 == 2147483648 in C# but not in VB.NET · c# .net vb.net hex. In C#: 0x80000000==2147483648 //outputs True.

  3. Jett

    • 2017/12/31

    This is related to the history behind the languages. C# always supported unsigned integers. The value you use are too large for int so the compiler picks the next type that can correctly represent the value. Which is uint for both. VB.NET didn't acquire unsigned integer support until version 8 (.NET 2.0). So traditionally, the compiler was forced to pick Long as the type for the 2147483648 literal.

  4. Javion

    • 2019/3/14

    0x80000000 is an unsigned literal with value 2147483648. According to the C Standard (6.4.4.1 Integer constants).

  5. Aldo

    • 2020/1/21

    This is related to the history behind the languages.

    C# always supported unsigned integers. The value you use are too large for int so the compiler picks the next type that can correctly represent the value. Which is uint for both.

    VB.NET didn't acquire unsigned integer support until version 8 (.NET 2.0). So traditionally, the compiler was forced to pick Long as the type for the 2147483648 literal. The rule was however different for the hexadecimal literal, it traditionally supported specifying the bit pattern of a negative value (see section 2.4.2 in the language spec). So &H80000000 is a literal of type Integer with the value -2147483648 and 2147483648 is a Long. Thus the mismatch.

    If you think VB.NET is a quirky language then I'd invite you to read this post :)

  6. Gregory

    • 2015/12/14

    return array[(a-b)&0x80000000];} also, you can make use of the C system stack to get rid of extra memory space: int max(int a,int b) {// in C standard, the function parameters are pushed from right to left. // so integer b is stored in high address. return array *(&a+((a-b)&0x80000000>>31));}

  7. Idris

    • 2016/7/15

    0x80000000 and 0xFFFFFFFF are both interpreted as "unsigned long int." This behavior is dictated by the C standard and by the sizes of the 

  8. Raymond

    • 2016/6/9

    Bits in a Float, and Infinity, NaN, and denormal CS 301 Lecture, Dr. Lawlor Bits in a Floating-Point Number Floats represent continuous values. But they do it using discrete bits.

  9. Milan

    • 2018/6/2

    This happens because the type of the hexadecimal number is UInt32 in C# and Int32 in VB.NET. The binary representation of the hexadecimal number is:

    10000000000000000000000000000000
    

    Both UInt32 and Int32 take 32 bits, but because Int32 is signed, the first bit is considered a sign to indicate whether the number is negative or not: 0 for positive, 1 for negative. To convert a negative binary number to decimal, do this:

    1. Invert the bits. You get 01111111111111111111111111111111.
    2. Convert this to decimal. You get 2147483647.
    3. Add 1 to this number. You get 2147483648.
    4. Make this negative. You get -2147483648, which is equal to &H80000000 in VB.NET.
  10. Morelli

    • 2021/6/22

    0x80000000 == 2147483648 в C#, но не в VB.NET. В C#: году 0x80000000==2147483648 //outputs True. В VB.NET году: &H80000000=2147483648 'outputs False.

  11. Ridge

    • 2019/11/16

    Builtin: eval (expression, [radix = ‘10’], [width]) Expands to the value of expression. The expansion is empty if a problem is encountered while parsing the arguments. If specified, radix and width control the format of the output. Calculations are done with 32-bit signed numbers. Overflow silently results in wraparound.

  12. Stone

    • 2021/8/21

    Why not simply write it as either -2,147,483,648 or 0x80000000? Looking at the C header file limits.h, we see that they use a similar method 

  13. Jaxxon

    • 2021/9/10

    Answer (1 of 4): An Int32 is a 32 bit signed integer. Int64 is a 64 bit signed integer. A signed integer will give you a positive or negative integer of 2 to the power n-1 minus 1 where n is the bit depth.

  14. Emilio

    • 2019/2/11

    In C, -2147483648 is not an integer constant. and the conversion of the resulting unsigned int 0x80000000 to int involves an overflow.

  15. Bryce

    • 2017/2/24

    In particular, when the compiler sees something like -2147483648, it parses this as unary minus applied to 2147483648. But the latter (a positive number) is too large for the int data type, and so may be wrapped around or otherwise modified. The same is the case for 0x80000000: It is parsed as an integer, but is too large for the int data type.

  16. Emmett

    • 2015/11/10

    Why not simply write it as either -2,147,483,648 or 0x80000000? Looking at the C header file limits.h, we see that they use a similar method 

  17. Braylen

    • 2016/11/27

    INT_MAX is 0x7FFFFFFF, so a decimal constant of 0x80000000 doesn't fit in a signed int, and if INT_MAX == LONG_MAX, not even in a

  18. Finn

    • 2018/5/19

    0x80000000 is an unsigned literal with value 2147483648. According to the C Standard (6.4.4.1 Integer constants) So -0x80000000 == 0x80000000 .

Comments are closed.

More Posts