Time for 64-bit longs?

michael at crlt.UUCP michael at crlt.UUCP
Sun Feb 22 08:15:05 AEST 1987


[Nybbling away...]

In article <848 at epimass.UUCP> jbuck at 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.
===========================================================================



More information about the Comp.lang.c mailing list