Xref: utzoo comp.lang.c++:13216 comp.lang.c:38955 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves From: daves@ex.heurikon.com (Dave Scidmore) Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: 64 bit architectures and C/C++ Message-ID: <472@heurikon.heurikon.com> Date: 1 May 91 21:42:26 GMT References: <168@shasta.Stanford.EDU> <13229@goofy.Apple.COM> Sender: news@heurikon.heurikon.com Reply-To: daves@ex.heurikon.com (Dave Scidmore) Organization: Heurikon Corporation, Madison, WI Lines: 59 turk@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@heurikon.com