Re: size of long long int on amd 64

[Vincent Torri <Vincent dot Torri at iecn dot u-nancy dot fr>]

Is there some differences about the size of intrinsic types in C++,
compared to C ?

Vincent Torri


On Mon, 28 Nov 2005, Nelson H. F. Beebe wrote:

> John Love-Jensen <eljay@adobe.com> writes on Mon, 28 Nov 2005 05:42:54 -0700 (MST):
>
> >> ...
> >> I'd have thought that on a 64-bit word-size architecture, int would be
> >> 64-bits big, long would be 128-bits big, and long long would be
> >> 256-bits big.
> >> ...
>
> No, the only requirement on C's integer data types is that
>
> 	sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
>
> subject to minimum size requirements on each of them that are
> specified in the ISO C Standard.  It is perfectly legal for all of
> these to have the same size, as long as they are big enough: on a
> 64-bit architecture, they all could be 64 bits long.  See section 5.1
> of this book, which deserves to be on every serious C programmer's
> shelf:
>
> @String{pub-PH                  = "Pren{\-}tice-Hall"}
> @String{pub-PH:adr              = "Upper Saddle River, NJ 07458, USA"}
>
> @Book{Harbison:2002:CRM,
>   author =       "Samuel P. {Harbison III} and Guy L. {Steele Jr.}",
>   title =        "{C} --- {A} Reference Manual",
>   publisher =    pub-PH,
>   address =      pub-PH:adr,
>   edition =      "Fifth",
>   pages =        "xviii + 533",
>   year =         "2002",
>   ISBN =         "0-13-089592-X",
>   ISBN-13 =      "978-0-13-089592-9",
>   LCCN =         "QA76.73.C15 H38 2002",
>   bibdate =      "Sat Mar 30 08:29:26 2002",
>   price =        "US\$45.00",
>   URL =          "http://www.CAReferenceManual.com/;
>                  http://www.phptr.com/ptrbooks/ptr_013089592X.html";,
>   acknowledgement = ack-nhfb,
> }
>
> It is common on many Unix systems for int and long to have the same
> size, and on IBM PC DOS, some compilers made short and int the same
> size.
>
> Here is what the 1999 ISO C Standard has to say (notice the
> requirement phrase: ``Their ... values shall be equal or greater in
> magnitude...'') [I've replaced superscripts in inline comments by
> Fortran's power operator **]:
>
> >> ...
> >>      5.2.4.2.1	Sizes of integer types <limits.h>
> >>
> >> 1    The values given below shall be replaced by constant expressions
> >>      suitable for use in #if preprocessing directives. Moreover,
> >>      except for CHAR_BIT and MB_LEN_MAX, the following shall be
> >>      replaced by expressions that have the same type as would an
> >>      expression that is an object of the corresponding type converted
> >>      according to the integer promotions.  Their
> >>      implementation-defined values shall be equal or greater in
> >>      magnitude (absolute value) to those shown, with the same sign.
> >>
> >>      -- number of bits for smallest object that is not a bit-field (byte)
> >> 	CHAR_BIT 8
> >>
> >>      -- minimum value for an object of type signed char
> >> 	SCHAR_MIN -127 // -(2**{7} - 1)
> >>
> >>      -- maximum value for an object of type signed char
> >> 	SCHAR_MAX +127 // 2**7 - 1
> >>
> >>      -- maximum value for an object of type unsigned char
> >> 	UCHAR_MAX 255 // 2**8 - 1
> >>
> >>      -- minimum value for an object of type char
> >> 	CHAR_MIN				     see below
> >>
> >>      -- maximum value for an object of type char
> >> 	CHAR_MAX				     see below
> >>
> >>      -- maximum number of bytes in a multibyte character, for any supported locale
> >> 	MB_LEN_MAX 1
> >>
> >>      -- minimum value for an object of type short int
> >> 	SHRT_MIN -32767 // -(2**15 - 1)
> >>
> >>      -- maximum value for an object of type short int
> >> 	SHRT_MAX +32767 // 2**15 - 1
> >>
> >>      -- maximum value for an object of type unsigned short int
> >> 	USHRT_MAX 65535 // 2**16 - 1
> >>
> >>      -- minimum value for an object of type int
> >> 	INT_MIN -32767 // -(2**15 - 1)
> >>
> >>      -- maximum value for an object of type int
> >> 	INT_MAX +32767 // 2**15 - 1
> >>
> >>      -- maximum value for an object of type unsigned int
> >> 	UINT_MAX 65535 // 2**16 - 1
> >>
> >>      -- minimum value for an object of type long int
> >> 	LONG_MIN -2147483647 // -(2**31 - 1)
> >>
> >>      -- maximum value for an object of type long int
> >> 	LONG_MAX +2147483647 // 2**31 - 1
> >>
> >>      -- maximum value for an object of type unsigned long int
> >> 	ULONG_MAX 4294967295 // 2**32 - 1
> >>
> >>      -- minimum value for an object of type long long int
> >> 	LLONG_MIN -9223372036854775807 // -(2**63 - 1)
> >>
> >>      -- maximum value for an object of type long long int
> >> 	 LLONG_MAX +9223372036854775807 // 2**63 - 1
> >>
> >>      -- maximum value for an object of type unsigned long long int
> >> 	 ULLONG_MAX 18446744073709551615 // 2**64 - 1
> >>
> >> 2    If the value of an object of type char is treated as a signed
> >>      integer when used in an expression, the value of CHAR_MIN shall
> >>      be the same as that of SCHAR_MIN and the value of CHAR_MAX shall
> >>      be the same as that of SCHAR_MAX. Otherwise, the value of
> >>      CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same
> >>      as that of UCHAR_MAX.15) The value UCHAR_MAX shall equal
> >>      2CHAR_BIT - 1.
> >> ...
>
> There are similar constraints on float, double, and long double: they
> can all be of identical size, provided that they satisfy minimum range
> and precision specified in the ISO C Standard.  I have used systems
> where this was the case, and also, where a char was nine bits (four
> then fitting in a 36-bit word).
>
> C's constraints on the sizes of floating-point types are different
> from Fortran, where the size of DOUBLE PRECISION is required to be
> twice that of REAL: that is essential knowledge for proper storage
> alignment in EQUIVALENCE statements and COMMON blocks.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
> -------------------------------------------------------------------------------
>