64 bit architectures and C/C++

[Dave Scidmore]

turk at Apple.COM (Ken "Turk" Turkowski) writes:

>It is necessary to have 8, 16, and 32-bit data types, in order to be able
>to read data from files.

Bad practice!!!! This works fine if the one reading the data is always the
same as the one writing it, but you are implying that these data sizes
are important for having a machine read files written by another machine,
then storing structures as binary images can result in severe problems. Byte
ordering is a more fundamental problem than the size of types when trying to
read and write binary images.

The world of microcomputers is divided into two camps: those who store the least
significant byte of a 16 or 32 bit quantity in the lowest memory location
(as in Intel processors), and those which store the most significant byte in
the lowest memory location (as in Motorola processors). Given the value
0x12345678 each stores 32 bit quantities as follows:

Memory address LSB
0	1	2	3
0x78	0x56	0x34	0x12	LSB in lowest address (Intel convention)
0x12	0x34	0x56	0x78	MSB in lowest address (Motorola convention)

>From this you can see that if a big-endian processor writes a 32 bit int
into memory a little endian processor will read it back backwards. The end
result is the need to swap all bytes within 16 and 32 bit quantites. When
reading structures from a file, this can only be done if you know the size
of each component of the structure and swap it after reading. In general
this is usualy sufficient reason not to store binary images of data in files
unless you can assure that the machine reading the values will always follow
the same size and byte ordering convention.

>I would suggest NOT specifying a size for the int
>data type; this is supposed to be the most efficient integral data type
>for a particular machine and compiler.

I agree.

>A lot of programs rely on the fact that nearly all C implementations
>have a 32-bit long int.

The precident for non-32 bit ints predates the microprocessor and anyone who
writes a supposedly "portable" program assuming long ints are 32 bits is
creating a complex and difficult mess for the person who has to port the
code to untangle.

>I would suggest:
>
>short	16 bits
>long	32 bits
>long long	64 bits
>int	UNSPECIFIED
>void *	UNSPECIFIED

I would suggest not making assumptions about the size of built in types
when writing portable code.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore at heurikon.com