long long integer types

[David Hough]

The following is a position paper arguing one approach to
the problem of 64-bit integer types.   I wasn't the author, but it seems
like a reasonable approach.
64-bit integers are one of the problem areas NCEG has looked at, 
inconclusively so far.

> What size should an int be?
> 
>      The basic question  is  what  size  basic  C  datatypes
> should  be  for  compilers  that  support  64-bit  pointers.
> Should the size of int and long change?  Do there need to be
> additional types?
> 
> The Answer
> 
>      The overwhelming concerns are to break as few  programs
> as  possible,  and  to  have  one source base, not two.  For
> those not wanting  to  read  further,  the position  must
> therefore be:
> 
>                        char        8
>                        short       16
>                        int         32
>                        long        32
>                        long long   64
> 
> Pointers will be 32-bits or 64-bits  depending  on  how  the
> program  is  compiled.  Many future chips will support
> either 32 or 64-bit pointers, while most current chips can only
> support 32-bit pointers.
> 
> We must not change the sizes of datatypes.
> 
> History
> 
>      History presents us with a dilemma.  Recently, pointers
> and  integers  have been the same size, namely 32-bits.  The
> PDP-11 C  had int and pointers being 16-bits.  In moving  to
> the  VAX, integers and longs and pointers were made 32-bits.
> Everything was re-compliled, and we moved on in  the  32-bit
> world.   Since  that  time,  most  programs make the defacto
> assumption that integers and longs are 32-bits.   GCC and
> other compilers are providing long long for 64-bit types.
> 
>      Traditionally, one would make int the same size as  the
> "natural"  register  width  of  the  computer.  Therefore it
> would be natural to think of int  as  64-bits  on  a  64-bit
> machine.  Long must be equal to or greater in size than int,
> so long would then have to be 64-bits.  Unfortunately,  this
> would  leave  us with no 32-bit type, which is clearly unac-
> ceptable.
> 
>      64-bit arithmetic can be supported on 32-bit computers,
> and  we  already have an industry wide defacto standard type
> of "long long" used for 64-bit integers.  This is  supported
> in GCC.
> 
> Why this time is different
> 
>      This is not the same case as moving from 16  to  32-bit
> computers,  and so we should not follow the same model.  The
> following are fundamental differences:
> 
> 1. We do not propose to  use  a  pure  64-bit  architecture.
> Most "64-bit" architectures will need to
> run today's existing 32-bit applications. It is likely  that
> 32-bit  applications  will  dominate  for  the  next 5 to 10
> years.  When we speak of 64-bit architectures, we really are
> talking about hybrid 32/64 bit computers.
> 
> 2. Operating systems will have to run on both 64-bit and  32-bit  com-
> puters.   Future installed  bases
> will be a mixture of old 32-bit computers, and new 32/64-bit
> computers.   We  care about applications portability with non-64-
> bit computers.   Changing  the
> size  of  long  and  int because of pointer size would force
> keeping two versions of the source in many cases.
> 
> 3. For applications to be portable, they  must  be  made  to
> compile  the identical source code on both 32-bit and 64-bit
> computers.  These compiled applications  must  then  product
> identical  results.   This  can not be done if each compiler
> presumes different datasizes.  Datasizes must  be  kept  the
> same, only pointers may be allowed to change size.
> 
> Example: Bad Code
> 
>      Unfortunately, poorly written code does  exist  in  the
> millions of lines of C code that exists today.  For example,
> the C statement
>                   x = ( a << 24 )  >> 24;
> is used to clear the top 24-bits  of  a  32-bit  integer  on
> today's  32-bit  cpus.   If integers were changed in size to
> 64-bits, this program  fragment  would  not  give  the  same
> result.   We  must  insure that newly compiled programs con-
> tinue to work.
> 
> Ask for it
> 
>      Programmers should have to explicitly  ask  for  64-bit
> datatypes or pointers.  Compilers should give clear diagnos-
> tic warnings about pointers storage in  integers  or  longs.
> 64-bit  types  will  be the exception, and it imposes little
> hardship since programmers are already getting 64-bit  types
> with long long today.