Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!cs.umn.edu!kksys!edgar!orac!bret From: bret@orac.UUCP (Bret Indrelee) Newsgroups: comp.lang.c Subject: Re: 64 bit architectures and C/C++ Summary: Just do it. Message-ID: <313@orac.UUCP> Date: 19 May 91 19:51:35 GMT Article-I.D.: orac.313 References: <16036@smoke.brl.mil> <1991May6.232116.11401@sq.sq.com> <1991May9.192156.19291@nightowl.MN.ORG> Organization: Technix Inc., Saint Paul MN, USA Lines: 40 In article <1991May9.192156.19291@nightowl.MN.ORG> det@nightowl.MN.ORG (Derek E. Terveer) writes: > >What is wrong with simply implementing the following in a compiler? > > char = 8 bits > short = 16 bits > int = 32 bits > long = 64 bits I agree, this is the best of many choices. The problems with it are: 1) You will use more data space because longs are twice as large. On a 64bit arch, this means problems in swapping. There is enough VA space, you just wouldn't be using as efficiently as if long was 32 bits. 2) You break programs that assume int is going to match the size of anything. Translation: you break programs that already can not be ported between available 32 bit machines that make a different choice (sizeof int == sizeof short) || (sizeof int == sizeof long) Fix the programs. 3) You break programs that don't use void pointers when they need a generic pointer. See #2 above. 4) You may find new bugs in programs, where an overflow that you never knew existed on a 32bit machine now makes your integer math come out different. Most of these come down to problems with programs that already don't work on existing 32 machines. Start using typedef and MAX_INT people. Your replacements will thank you rather than curse you. -Bret -- ------------------------------------------------------------------------------ Bret Indrelee | bret@orac.edgar.mn.org | ;^)