Subject: Re: long long vs long
From: [email-masked] (Andrew Sharp)

23 Jul 1998 03:51:44 -0700
Message-ID: <[email-masked]>
References: <73B8DC108A44D111B44700805FF5C69D01E51F@cware>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "[email-masked]'" <[email-masked]>

Graham Murray wrote:
> 
> 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.

You're right, it is a silly question.  ~:^)  I did a lot of 64bit unix
kernel porting work a few years back, and the reason that something
other than 'long' had to be used is that there is about 6 trillion lines
of C code in the world that would seriously break if long's suddenly
became 64 bits, because coders have been using 'long' for more than a
decade with the belief that they are the same size as 'int'.  Avoiding
the discussion of why they didn't use 'int' all those times, suffice it
to say that a new type was created for the sake of expediency.  Everyone
who has written code that might require some fixin' if long's changed to
64 bits, raise your hand.

The irony is that types like 'long long' are usually accomplished in
some basic header, not as a base compiler type.  The base compiler 64bit
types are almost always of the form '_int64' or some such.  It seems we
just can't ever separate int's and long's!

a
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".