Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!ut-sally!ut-ngp!dlnash
From: dlnash@ut-ngp.UUCP
Newsgroups: comp.lang.c
Subject: Re: standardizing integral type sizes
Message-ID: <4969@ut-ngp.UUCP>
Date: Wed, 8-Apr-87 12:10:26 EST
Article-I.D.: ut-ngp.4969
Posted: Wed Apr  8 12:10:26 1987
Date-Received: Sat, 11-Apr-87 09:03:55 EST
References: <791@xanth.UUCP>
Organization: UTexas Computation Center, Austin, Texas
Lines: 34

In article <791@xanth.UUCP>, kyle@xanth.UUCP (kyle jones) writes:
> I would like to see the sizes of C integral types standardized.
> [...]
> 
> One proposal might be:
> 
> 	char	 8 bits
> 	short	16 bits
> 	int	32 bits
> 	long	64 bits
> 

This is a good idea in theory, but not in practice.  What do you do
about machines which don't have a word size which is some power of two
(like CDC Cybers or DEC-20s)?  Doing 64 bit arithmetic on a machine with
a 60 bit word size (Cybers) or a 36 bit word size (DEC-20s) would be
extremely difficult.  Another idea would be something like this:

        char    at least  8 bits (possibly more)
        short   at least 16 bits (possibly more)
        int     at least 32 bits (possibly more)
        long    at least 64 bits (possibly more)

Then you would have at least the range you expected.  The compiler could then
choose the size most advantageous for your machine.  If you need to construct
bit masks which depend on the operand size (not usually necessary, usually a
bad idea), you can use our old friend sizeof.

				Don Nash

UUCP:    ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash
ARPA:    dlnash@ngp.UTEXAS.EDU
BITNET:	 CCEU001@UTADNX, DLNASH@UTADNX
TEXNET:  UTADNX::CCEU001, UTADNX::DLNASH