assigning 64-bit hex values to unsigned long variables

[shortyzms]

I'm having a problem with assigning 64-bit hex values to unsigned long variables in MS VS2005 c++ compiler.

unsigned long Number;
Number = 0x1000000000000000UL;

After this declaration and assignment, the value in Number is always 0. However, if the hex value is 0x0000000000000 001, then the value is 1 as expected. It seems like the compiler is truncating the most significant 32 bits. How can I make this work?

[JosAH]

I'm having a problem with assigning 64-bit hex values to unsigned long variables in MS VS2005 c++ compiler.

unsigned long Number;
Number = 0x1000000000000000UL;

After this declaration and assignment, the value in Number is always 0. However, if the hex value is 0x0000000000000 001, then the value is 1 as expected. It seems like the compiler is truncating the most significant 32 bits. How can I make this work?

Maybe you should try:

unsigned long long Number;

kind regards,

Jos

[weaknessforcats]

Good Luck. sizeof(unsigned long long) is 8. That is, VS2005 is a 32-bit compiler.

The OP should be using a 64-bit compiler.

[donbock]

Maybe you should try:

unsigned long long Number;

And

Number = 0x1000000000000000ULL;

To the OP: what gave you the impression that your compiler supports 64-bit integers? The C Standard only requires 'long' and 'unsigned long' to support 32-bit integers. Compilers are permitted to support wider integers, but a portable program shouldn't rely on such largesse.

C99 (and C++?) added 'long long' and 'unsigned long long'. Don't know about C++, but C99 requires these types to be at least 64-bits wide. Refer to <limits.h> for your particular compiler's type sizes.

[donbock]

Good Luck. sizeof(unsigned long long) is 8. That is, VS2005 is a 32-bit compiler.

I think a sizeof of 8 is 64 bits.

[shortyzms]

Thanks for the tip JoS, it worked like a charm!

To the OP: what gave you the impression that your compiler supports 64-bit integers? The C Standard only requires 'long' and 'unsigned long' to support 32-bit integers. Compilers are permitted to support wider integers, but a portable program shouldn't rely on such largesse.

I was given the impression that 'long' always meant 64 bits. I didn't know that the standard only requires 'unsigned long' to support numbers in the range of an unsigned 32-bit integer.

C99 (and C++?) added 'long long' and 'unsigned long long'. Don't know about C++, but C99 requires these types to be at least 64-bits wide. Refer to <limits.h> for your particular compiler's type sizes.

Thanks for this tip!

[Banfa]

Good Luck. sizeof(unsigned long long) is 8. That is, VS2005 is a 32-bit compiler.

The OP should be using a 64-bit compiler.

It may be but long long equates to a 64bit integer on it in the same way that a decade or so ago long was a 32bit integer even when the compiler was compiling for a 16bit target (actually that is still true for all those 16bit microprocessor that are still being manufactured)

Try this on you VS2005 install

#include <stdio.h>
#include <limits.h>

int main(int argc, char **argp)
{
    unsigned long long Number = ULLONG_MAX;

    printf("Number: size(%d) Value=%I64x\n", sizeof Number, Number);

    return 0;
}

[Banfa]

I was given the impression that 'long' always meant 64 bits. I didn't know that the standard only requires 'unsigned long' to support numbers in the range of an unsigned 32-bit integer.

Actually the standard (for C) only requires that

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

and

sizeof(char) == 1

C++ is a little more stringent than this. Additionally the number of bits in a char is variable (normally dependent on the hardware platform) although 8 bits in a char is far and away the most common configuration.

From that you can see that it would be possible to have a platform where all integers where 8 bit although that would certainly not be useful.

Again most commonly

a byte has 8 bits
sizeof(char) == 1 (by definition a char is 1 byte)
sizeof(short) == 2
sizeof(int) == 2 or 4
sizeof(long) == 2 or 4

The only slight problem is that int is supposed to be the size of integer that the platform can process most easily, hence it is 2 or 4 bytes depending on if the platform is 16 or 32 bit. Strictly speaking that means that on modern 64 bit platforms sizeof(int) should be 8 (and therefore sizeof(long) should be 8 or greater) but most of the compiler manufacturers didn't do this I believe because they where afraid of breaking everyone else's software.

In case you are wondering C++ adds the additional specifications that short and int should be a minimum of 16 bits and long should be a minimum of 32 bits (I think).

[donbock]

This note is excessively pedantic ... but I love that stuff!

Section 5.2.4.2.1 of C89 (um ... I'm not sure if that's ANSI or ISO section numbering ... if you know what I mean by this comment then congratulations , you're an official C pedant) sets minimum limits on the sizes of the integer types. The "implementa tion-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign."

minimum value for an object of type signed char: -127

maximum value for an object of type signed char: +127 (0x7F)

maximum value for an object of type unsigned char: 255 (0xFF)

minimum value for an object of type short int: -32767

maximum value for an object of type short int: +32767 (0x7FFF)

maximum value for an object of type unsigned short int: 65535 (0xFFFF)

minimum value for an object of type long int: -2147483647

maximum value for an object of type long int: +2147483647 (0x7FFFFFFF)

maximum value for an object of type unsigned long int: 4294967295 (0xFFFFFFFF)

From these numerical limits it is clear that char must be at least 8 bits wide, short must be at least 16 bits wide, and long must be at least 32 bits wide.

The necessary relative sizes of these types are just as Banfa stated, however that relationship is specified elsewhere in C89, and I'm not taking the time to track it down.

[weaknessforcats]

The above is only true for ASCII as the C implementation character set. This covers 99.999% of the C implementations .

However, if your compiler uses another character set, the above are not true. Some microprocessors used by Boeing to simulate the 757 cockpit did not use ASCII. They had a version of TinyC.