From: Chris Croughton <crough45 AT amc DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: 64 bit integers ??!?
Date: Wed, 21 Jan 1998 10:54:15 +0100
Message-ID: <34C5C5C7.FF6@amc.de>
References: <C1256592 DOT 002E78CA DOT 00 AT vega DOT ads DOT it> <34C56EE0 DOT 1F9D AT cs DOT com>
NNTP-Posting-Host: bob.bob.bofh.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 35
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

John M. Aldrich wrote:
> 
> That's the limit of the ANSI restrictions.  However, most
> implementations preserve longs as 32 bits, simply because most
> architectures _are_ 32-bit, and most code assumes long to be 32 bits.

Such code breaks on the DEC Alpha.

> 64-bit integer implementation is spotty at best; perhaps when 64-bit
> systems become more prevalent we'll see a change.

On the DEC Alpha (which is 64-bit RISC) the sizes are:

  short		16
  int		32
  long		64

And the GNU extension "long long" is the same as long (largely
because the 64-bit operations are builtin and 128-bit are not
very easy, the Alpha has no carry bit!).

Note that in this implementation a pointer can't fit into an int,
either, you have to use a long.  And things like:

  char buff[256];
  unsigned int i;

  ... buff[256-i] ...

don't work - (256-i) is taken as unsigned (because i is unsigned),
which gives a large (but only 32 bit) unsigned number.  This added
to the pointer/array gives an invalid address.  Not an easy bug
to find...

Chris C