Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!amdcad!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: 64 bit ints
Message-ID: <8803@smoke.BRL.MIL>
Date: 30 Oct 88 20:24:00 GMT
Article-I.D.: smoke.8803
References: <6264@june.cs.washington.edu> <225800084@uxe.cso.uiuc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <225800084@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
-Then allow the user to specify, either by an "install" program,
-by command line switches, by a "config" file, or by (gasp) pragmas,
-whatever combination of shorts, ints and longs he wants, so
-long as they fit the usual rules of C. Some people will use 
-short = int = long int = 64 while others will put short = int = 16
-and long int = 64 (to match pointers) or whatever.

This is unworkable.  The application code has to interface with the
C library and other libraries.  It is unrealistic to expect there to
be umpteen variants of each library to support all the permutations
of data sizes.

It is also a BAD idea to make int handling slower than necessary
by an inappropriate choice.  int has always been intended to be the
integer type "most convenient for the machine".