Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  Re: Uses of \"short\" ?
Message-ID: <2081@brl-tgr.ARPA>
Date: Sat, 12-Oct-85 03:45:46 EDT
Article-I.D.: brl-tgr.2081
Posted: Sat Oct 12 03:45:46 1985
Date-Received: Mon, 14-Oct-85 03:44:48 EDT
Sender: news@brl-tgr.ARPA
Lines: 25

I don't see what "trapping integer overflows" has to do with this
topic.  Using the wrong size integer can fail in other ways.

There is absolutely no use for types "int8", "int16", and "int32"
since the shortest C types that fit them can always be used:
"signed char", "short", and "long".  The only possible merit to
introducing types like this would be to represent some oddball
size such as "int24", which might be a "short" on a 24-bit machine
and a "long" on 16- or 32-bit machines.  In the VERY RARE case
that you have to minimize storage on a 24-bit machine, you might
well define "int24" accordingly and use it JUST for the large
storage-consuming data type, with an #ifdef to define it right
for your specific machine and as "long" otherwise.

Similarly, "int60" will only be used where C guarantees non-
portability.  If for some reason you really have to exceed 32
bits in an integer data type and cannot afford the overhead of
doing it portably, then certainly defining "int60" (ONLY for
your specific machine) will cause the portability problem to
become very visible when the code finally is ported, which is
undoubtedly better than having the code fail mysteriously.

General use of unnecessary names like "int8", "int16", and "int32"
just makes it harder for others to maintain your code without
contributing anything whatever to the portability of the code.