Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!sri-spam!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Time for 64-bit longs?
Message-ID: <12302@sun.uucp>
Date: Thu, 29-Jan-87 03:21:08 EST
Article-I.D.: sun.12302
Posted: Thu Jan 29 03:21:08 1987
Date-Received: Sat, 31-Jan-87 02:30:31 EST
References: <848@epimass.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 25
Xref: watmath comp.lang.c:884 comp.unix.wizards:743

>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.

I suspect there is a lot of NON-Berkeley code that makes the
assumption that "long" is 4 bytes, 32 bits, or whatever.
Unfortunately, C lacks a general way to ask for data that are some
particular size, however you choose to define this size; you can't
ask for subranges, and the only way you can ask for some specific
number of bits is to ask for a bit field - but bit fields are not
first-class citizens.

>But it seems the Vax architecture will soon require a 64-bit type at the
>high end.

The VAX architecture already has some support for "quad"s, although
there may not be as many instructions that support them as there are
instructions to support shorter types (although this may not be
necessary if the use of "quad"s would mostly be limited to dealing
with addresses in huge files).

However, I think the chances are pretty slim that this type would
replace "long"s, either in the sense of "long"s in C or "long"s in
the VAX architecture.  If it appears, the chances are very good that
it will appear in VAX C implementations as "long long int" or
something like it.