🚀 go-pugleaf

In article <rpfbuqg1t7g.fsf@unicorn.bbn.com>, Chris Jones  <clj@bbn.com> wrote:
>In article <483pe6$aft@spool.cs.wisc.edu> tuc@.cs.wisc.edu (Brian Cole) writes:
>   I'm confused as to why a compiler writer would make a new "long long" type
>   instead of making "long" be a 64-bit integer.  That way "char", "short",
>   "int", and "long" would be 1, 2, 4, and 8-byte integers, respectively,
>   and coders could stick to legal ANSI C.  I've been waiting for C compilers
>   to make this switch for a few years now.
>
>Kendall Square Research's C compiler used this scheme.  One thing we (I was at
>KSR for nearly 7 years) found was that there is a lot of code which "knows"
>that pointers can fit into ints, and that wasn't true on KSR machines.

  Where I work, everyone's fallen to the convention of using type
names "int8" "int16" "int32" and "int64" in their code.  We try to
keep everything machine-specific hidden in a header file, so that
all we have to do to port is change the name of the header file
and recompile.  In msdos.h, for instance, we have class declarations
for 64-bit integer types, while int32 is typedef'd to long, int16 is 
typedef'd to short, and int8 is typedef'd to signed char.
  If at any point in the future we wanted to work on a 64-bit machine
we'd just typedef the int64 to whatever convention the compiler used
for the native 64-bit integer type.

  It makes bit-diddling much less scary, since the size of an 
integer is known absolutely.  None of this "urk .. is int 16