🚀 go-pugleaf

earlier I wrote:
] 
] 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.
] 
] Assuming that the compiler supports a "long means int" option so it can
] compile legacy code, what reason is there to leave "long" 32 bits?


meissner@cygnus.com (Michael Meissner) replied:
> 
> Because in the case of the GNU compiler, it needs to fit in with the host
> system using the host libraries, and most 32-bit host compilers define long
> to be 32 bits.

Ah, I hadn't thought of that.  So with any luck the host libraries will
eventually be modernized.


dsiebert@icaen.uiowa.edu (Doug Siebert) replied:
} 
} Making int 32 bits is certainly the wrong approach.  'int' is supposed to
} be the longest type the machine handles natively -- so on a machine with 16
} bit registers an int should be 16 bit, 32 on 32, and 64 bits on a 64 bit
} machine.

I disagree with this statement.  There's good reasons why (years ago) many
C-compilers for machines with 32-bit registers had "int"s be (or at least
default to) 16-bit.

If Doug's statement where true, then why bother to have a "long" type at
all?  Change "longest type the machine handles natively" to "most
convenient size from the point of view of the hardware and the OS" then
maybe it's true.


brian
-- 
~~~~~~~~~~~~~~~~~~~   _______    _____   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Brian A. Cole      |_   _  |  |  ___|        visit Brian's Mac Serial 
  Head Consultant      | | | |__| |___         Port Summary document at
  tuc@cs.wisc.edu      |_| |__________|    http://www.cs.wisc.edu/~tuc/mac/