Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps
From: tps@sdchem.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Time for 64-bit longs?
Message-ID: <629@sdchema.sdchem.UUCP>
Date: Tue, 3-Feb-87 00:31:36 EST
Article-I.D.: sdchema.629
Posted: Tue Feb  3 00:31:36 1987
Date-Received: Wed, 4-Feb-87 03:24:59 EST
References: <848@epimass.UUCP> <291@mtxinu.UUCP>
Sender: news@sdchem.UUCP
Reply-To: tps@sdchemf.UUCP (Tom Stockfisch)
Organization: UC San Diego
Lines: 36
Xref: watmath comp.lang.c:924 comp.unix.wizards:796

In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) 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.
>
>The problem is not that the VAX code assumes int == long (it often
>does make that assumption, but those are bugs) but that C defines
>only two sizes of integer: long and short.  Int may be either,
>depending on the implementation, but it must be one or the other.
>Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA

Wrong.
(Perhaps this is an example of "if I've never seen anybody do it, I guess
there must be a law against it"?:)

K&R p. 34

	"...each compiler is free to interpret 'short' and 'long' as
	appropriate for its own hardware.
	...all you should count on is that 'short' is no longer than 'long'"












|| Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.UCSD