Subject: Re: long long vs long
From: [email-masked] (Nicholas R LeRoy)

23 Jul 1998 01:25:58 -0700
Message-ID: <9807220855.ZM16276.cygnus.gnu-win32@dopey>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Graham Murray <[email-masked]>,
        "[email-masked]
 '" <[email-masked]>

On Jul 21,  8:01am, Graham Murray wrote:
> Subject: long long vs long
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

Several reasons, actually.

Technically, it doesn't make sense, at least in the PC world, where
all processors are <=32bits.  Any 64-bit operation takes 2 separate
accesses and math, etc., becomes more complicated (and requires more
instructions and time).

Probably the more pervasive reason, however, is that there exists A
LOT of code out there which expects sizeof(long)==4.  It's sort-of an
un-official C standard.  In particular, legacy code dealing with
networking, etc., is frequently very loaded with such assumptions.
IIRC, the original CRAY C compiler used a 32-bit long and a 64-bit
int, just because so much code had this expectation.  IMHO: C should
have included standard data sizes, as well as it's generic types.  It
would have made many things a lot simpler.

Just my $.02 worth.

-Nick

-- 
+-------------------------------+--------------------------------------------+
| /`--_   Nicholas R LeRoy      | In a world without fences, Who needs Gates?|
|{     }/ Norland Corporation   |        ---- Experience Linux! ----         |
| \ *  / W6340 Hackbarth Rd     | http://www.linux.org | http://www.ssc.com  |
| |___| Fort Atkinson, WI 53538 +--------------------------------------------+
|      [email-masked]   | #include <disclaimer.h>                    |
|http://www.norland.com/~nleroy | These are my own ideas, not my employer's. |
+----------------------------------------------------------------------------+
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".