Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utfyzx!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.lang.c
Subject: standardizing integral type sizes
Message-ID: <1987Apr9.155110.28398@sq.uucp>
Date: Thu, 9-Apr-87 15:51:10 EST
Article-I.D.: sq.1987Apr9.155110.28398
Posted: Thu Apr  9 15:51:10 1987
Date-Received: Sat, 11-Apr-87 10:48:22 EST
References: <101@umich.UUCP> <791@xanth.UUCP>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto
Lines: 66
Checksum: 16406
Summary: No!

Johnathan Tainter (jtr485@umich.UUCP) writes:

> short, int, long is the dumbest part of C.  The language should have said
> there will be a class of types int<ext> where <ext> is the number of bits.
> [You should] add macros ... so you CANNOT use int, long etc.

And Kyle Jones (kyle@xanth.UUCP) writes:

] I would like to see the sizes of C integral types standardized.  It would be
] much easier to write portable code if when I define a variable as an 'int' I
] could automatically know... its range... [e.g.] char 8 bits, short 16, ...

This comes up all the time, but perhaps it is worth rebutting it again.
The first reason these notions are bad is the presumption that there are
only a very small number of word sizes.  What do you do on a 36-bit 
machine, for instance?

The second thing is, yes, efficiency.  The Draft Standard DOES specify
MINIMUM ranges for the different types.  In effect it guarantees...

	char <= short <= int <= long
	char >= 8 bits, short >= 16 bits, int >= 16 bits, long >= 32 bits

... with the further presumption, which has been part of C for a long
time, that int operations are at least as efficient as other types.

What this means is that if you always use

	if you may need more than 16 bits,
		long
	else if time efficiency matters more than space efficiency,
		int
	else
		short or char

then your compiler will give you what you really need in the way most
suited to WHATEVER machine you may run on.  Now how can you do better
than that?

Well, the world is not quite as perfect as I am implying here.  If you
require variables exceeding 32 bits, your code is certainly nonportable
whatever you do, because no variable is guaranteed such accuracy.
Also, the Draft is not yet a Standard, and I've heard of compilers where
short = 8 bits.  (No, I don't remember which ones.)  Finally, char may
be signed or unsigned on different machines.  (The Draft takes care of
this by defining a "signed char"; then "char" may be like "signed char"
or like "unsigned char" depending on the machine, and should only be
used for actual character values.)

But for the usual range of sizes and portability issues, following the
above guidelines works just fine.  Thinking you have to know the range
of values of a type is a holdover from other languages; knowing the
MINIMUM range is quite sufficient.

Oh, and by the way...

> > 	casting.  The assignment operator is pretty forgiving...it
> > 	knows what the types on both sides need be.
> Assignment had better be forgiving since type casts are defined in
> terms of it.

Not in the Draft Standard.  They're both defined in terms of type
conversion.  Indeed, the Draft REQUIRES certain conversions involving
pointers to be done by casting, e.g. char *cp; int *ip; ip = (int *) cp;

Mark Brader