Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!lll-lcc!well!msudoc!crlt!michael
From: michael@crlt.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Time for 64-bit longs?
Message-ID: <651@crlt.UUCP>
Date: Sat, 21-Feb-87 17:15:05 EST
Article-I.D.: crlt.651
Posted: Sat Feb 21 17:15:05 1987
Date-Received: Mon, 23-Feb-87 02:48:57 EST
References: <848@epimass.UUCP> <260@vax1.ccs.cornell.edu> <66@umich.UUCP>
Organization: CRLT , Ann Arbor, MI
Lines: 26
Summary: Here's some possible names... (at least half serious)
Xref: watmath comp.lang.c:1121 comp.unix.wizards:1077

[Nybbling away...]

In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
>has a monstrosity called a "long long" that's 64 bits; they leave
>long as 32 bits, the same as int, apparently because it was too hard
>to change all the Berkeley code that assumes long == int.  But it
>seems the Vax architecture will soon require a 64-bit type at the
>high end.

On the side issue of naming them, how about "longer"s (for 64 or so),
"longeryet"s (for 128) and "longest"s (guaranteed to be the largest
you've got)?  This just adds new types, rather than a new syntax, to
the language.

(One would like "long" to keep its original meaning as "longest integer",
but that would expand the data segments of many existing programs.)

===========================================================================
  "I've got code in my node."	| UUCP:  ...!ihnp4!itivax!node!michael
				| AUDIO: (313) 973-8787
	Michael McClary		| SNAIL: 2091 Chalmers, Ann Arbor MI 48104
---------------------------------------------------------------------------
Above opinions are the official position of McClary Associates.  Customers
may have opinions of their own, which are given all the attention paid for.
===========================================================================