Re: amd64: why is sizeof(int) =4? why not =8?
Miquel van Smoorenburg wrote:
In article <[🔎] 1144244740.27250.8.camel@haggis.homelan>,
Ron Johnson <ron.l.johnson@cox.net> wrote:
On Wed, 2006-04-05 at 06:48 -0500, Mitchell Laks wrote:
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
No, he's talking about the instruction set.
32 bits. Remember it's just a C data type.
The GCC guys also made a decision, but that's not the one he's
referring to.
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
This is not every size of integer. I have used machines with
18 bit integers, 24 bit integers, and 36 bit integers. There
were even machines which used base 3 for a while (trits), but C
insists that integral types use a pure binary storage, though
which one is unspecified. (I've used at least three I can think
of right off.*) Anyway, there is nothing to preclude that
CHAR_BIT is 8, and sizeof(int) is 3 or 12.
We loved those 36 bit integers and FORTRAN. That machine used
true ASCII, that is 7 bit characters. So we could read with A5
format, and have one bit LEFT OVER to do ANYTHING WE WANTED TO
WITH. (Although CHAR_BIT cannot be 7, so this trick can't be
used with C.)
(irony, in case you didn't notice)
On another note...
The IBM 6250 was a sort-of natural octal/hex machine, but the ALU
used tables loaded from cards to do arithmetic, and it could
be programmed to do decimal arithmetic as well. Some wiseacres
sometimes programmed other, unusual, bases. There are possibly
more decimal computers in the world today than binary ones.
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.
This was one of the rationales for introducing the size_t and
ptrdiff_t types. Also, one should realize that sizeof(int *),
sizeof(char *), and sizeof(int (*)()) may not be the same,
though sizeof(void *) and sizeof(char *) are guaranteed to
be the same, and to have the same format in memory. So
void *Vp;
char (*Fp1)(), (*Fp2)();
Fp1 = <some valid pointer to function expression>;
Vp = Fp1;
Fp2 = Vp;
May not have the same results as
Fp1 = <some valid pointer to function expression>;
Vp = (Fp2 = Fp1);
as Fp2 may not have the same value. The former code risks Fp2 being
invalid due to type conversion to (void *) along the way.
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.
Umm, there's a type for that, so for portability use int_least64_t.
* For unsigned types, it's all laid out, but for signed integral
types, the format of storage is unspecified. I've used signed-
magnitude (two styles), ones-complement, and twos-complement machines
at least. I may have used others, but if I have, I don't recall it.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply to: