Thread: sizeof iint-vs-long_int

  1. #1
    Registered User
    Join Date
    Mar 2014

    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

    int x = 0xAB78 in decimal format is : 43896
    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 -

    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?


  2. #2
    Registered User
    Join Date
    Jun 2005
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    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.

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    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?

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


    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".

    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  5. #5
    Join Date
    Oct 2007
    Inside my computer
    Quote Originally Posted by MutantJohn View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User
    Join Date
    Dec 2006
    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.

    int x = 0xAB78;
    is exactly the same as
    int x = 43896;

  7. #7
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Portland, OR
    0xAB78 is only 16 bits wide... Maybe that's why it isn't doing what you think.
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Sizeof
    By ncode in forum C Programming
    Replies: 5
    Last Post: 01-14-2012, 03:53 AM
  2. Replies: 5
    Last Post: 12-09-2010, 02:33 PM
  3. Replies: 6
    Last Post: 10-15-2007, 08:05 AM
  4. sizeof(cin) and sizeof(cout)
    By noobcpp in forum C++ Programming
    Replies: 11
    Last Post: 06-30-2007, 11:00 AM
  5. sizeof
    By agarwaga in forum C Programming
    Replies: 9
    Last Post: 10-18-2005, 08:34 AM