sizeof iint-vs-long_int

Not sure if this is hardware, software or compiler dependent

$ uname -a
CYGWIN_NT-5.1 machinename 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin

On a 32 bit XP SP 3 platform

wrote a small profram to check some parameters;
Received the following Re: Signed and unsigned integers

Quote:

---

int x = 0xAB78 in decimal format is : 43896
and
unsigned int y = 0xAB78 in decimal format is : 43896
The size of int is 4 bytes

---

Not quite what I expected, since the leftmost bit in 'int' is 1 and would be the negative flag.

So wrote another for byte sizes and got the following -

Quote:

---

The size of short int is 2 bytes
The size of int is 4 bytes
The size of long int is 4 bytes
The size of double is 8 bytes
The size of long double is 12 bytes

---

Note: size of 'int' and 'long int' are the same, both are 4 bytes long

Is this to be expected?

Thanks!

It's more accurate to say the results you obtained are not unexpected. They are reasonable in practice, but not guaranteed by the standard.

Variables are initialised by value. Using a hex value as an initialiser of an int does not specify anything in terms of the individual bits which make up that int. You are 100% incorrect in your assertion that the leftmost bit in an int is the "negative flag" - the standard requires no such thing, and there are real compilers that do not do as you suggest.

There is a wrinkle that an int is not guaranteed able to represent a value of 43896, and the results of overflowing an int are undefined. The range of values that an int can represent is implementation defined. Specifically, the standard requires an int be able to represent all values in the range [-32766,32766], but does not forbid a compiler supporting a larger range. Your compiler clearly supports a range large enough so it CAN represent 43896 so, accordingly, the value of x when initialised as 0xAB78 is required to yield (the equivalent in decimal) value of 43896.

The size of all types (except char types, for which sizeof() is defined to be 1) is implementation defined (i.e. sizeof any type can vary between compilers). The values of sizes you obtained are not unexpected, but also are not guaranteed. The only requirement imposed by the standard is that sizeof(anything) yields a positive value. Specific values are not required.

For me an int is 4 bytes and a long one is 8. I'm 64 bit architecture but that shouldn't matter. Are you sure your code is correct?

Also, assuming you have 32 bits and they're all set to 1, the hex values should read the same. Hex is just a shorthand way of writing out binary using 4 bit increments (hence the hexadecimal name). It's all up to how the machine interprets the data because a float, unsigned int and signed int all look the same to the computer. It's all in how you interpret the binary.

Quote:

---

For me an int is 4 bytes and a long one is 8. I'm 64 bit architecture but that shouldn't matter. Are you sure your code is correct?

---

O_o

The architecture doesn't matter in the slightest. You'd hope they would relate to native support, but that isn't even a guarantee.

*shrug*

The Embarcadero compiler have compatibility flags making `sizeof(int) == 2', `sizeof(int) == 4', `sizeof(long) == 4', and `sizeof(long) == 8'.

The compiler determines the "relative widths".

Soma

Quote:

---

Originally Posted by MutantJohn

For me an int is 4 bytes and a long one is 8. I'm 64 bit architecture but that shouldn't matter. Are you sure your code is correct?

---

It is common for long to be 4 bytes on 32-bit architectures and 8 bytes on 64-bit architectures (on Linux; still 4 [with MSVC] on Windows). No weirdness here.

I think the misconception to realize here is that the only difference between specifying a number in hex vs decimal is only the base.

If you assign 0xAB78 to a variable, that is EXACTLY equivalent to assigning 43896 to the variable.

Using hex does not magically mean it will automatically be interpreted as a bit pattern in two's complement or anything like that.

Code:

---

int x = 0xAB78;

---

is exactly the same as

Code:

---

int x = 43896;

---

0xAB78 is only 16 bits wide... Maybe that's why it isn't doing what you think.