From: andy AT accrue DOT com (Andrew Sharp)
Subject: Re: long long vs long
23 Jul 1998 03:51:44 -0700
Message-ID: <35B63CE6.4CA3924F.cygnus.gnu-win32@accrue.com>
References: <73B8DC108A44D111B44700805FF5C69D01E51F AT cware>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "'gnu-win32 AT cygnus DOT com'" <gnu-win32 AT cygnus DOT com>

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
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".