Re: amd64: why is sizeof(int) =4? why not =8?
In article <email@example.com>,
Ron Johnson <firstname.lastname@example.org> wrote:
>On Wed, 2006-04-05 at 06:48 -0500, Mitchell Laks wrote:
>> I wanted to find out more about amd64, so I installed the debian distro
>Did you install the 64 bit version?
>> (etch/sid) on my amd64 dual core system.
>Which one? Etch or Sid?
>> I wanted to see if it is really 64 bit. So naively i compiled the following
>> example program I found on the internet:
>> Size of double is 8
>> So how do I see the 64 bittness of the operating system if not this way with
>> gcc? I would think tha size of int would be 8?
>> uname -a
>> Linux Rashi 188.8.131.52-meshulum-2006-4-5 #1 SMP Wed Apr 5 13:34:46 EDT 2006
>> x86_64 GNU/Linux
>If you did actually install the 64 bit build, do a sizeof(int *)
>and you'll see that it is 64 bits.
>AMD decided that, to help with compatibility with s/w written when
>sloppy programmers assumed that sizeof(int) == sizeof(*), integers
>will be 32 bits, even in 64 bit mode.
Hmm? That's a decision of the GCC guys. They decided to make int
32 bits. Remember it's just a C data type.
It makes sense because this way, you have a standard C data type
for every size of integer:
char 8 bit
short 16 bit
int 32 bit
long 64 bit
And this does not help compatibility with s/w written by sloppy
programmers who assime that sizeof(int) == sizeof(*), in fact it
breaks that compatibility, because sizeof(*) == 8. You can generally
assume that sizeof(long) == sizeof(*) on most Linux platforms nowadays
though. That will probably break on future 128-bit systems.
>64 bit integers are of type "long long" and int64, which are just
>different names for the same type.
On most current Linux platforms, yes, but on 128 bit platforms,
long long will likely be 128 bits.
And on amd64 with gcc, "long" is also 64 bits.
If you need exactly 64 bits, int64 is your best bet. If you need
at least 64 bits, long long will probably work fine.