64 bit ints

[Mike Murphy]

	From earlanetcom.netcom.com Fri Dec 20 11:59 PST 1991

	Here is my perspective on the 64 bit issue:

I agree with much of what earl says here, but I do have a few disagreements:

	(4) "long long" is a terrible name for the new type because it cannot
	be #define'd or typedef'd.  If you're a single manufactor, "long long"

I don't see this.  You can easily do
	typedef long long bigint;
or
	#define bigint long long
The only thing you can't do is redefine "long long" via defines to be 
something else, but I see no reason to support such terrible code.

	(5) There needs to be an implementation-independent way to get
	integers of a fixed size.  Personally I would prefer a Pascal range
	for specifying this, but I have a feeling that won't fit into C well,
	so I propose instead
		#include <sizedints.h>
		int8, int16, int32, int64
		uint8, uint16, uint32, uint64
	(for 36-bit machines out there, these types are defined to contain at
	least the indicated size, not exactly the indicated size.)

I think this would be very useful, and would like to see NCEG push something
like this as a standard header.

	(7) Since implementations are still free to define the basic C types
	as they like, the following is only a suggestion.  For implementations
	that support a 64-bit address space, I believe that "int" should be 64
	bits.  There are several reasons why I think that this is the only
	sane choice:

As mentioned, I don't think this is something that NCEG should define,
but it's fun to argue about, and I prefer making int be 32 bits, and
long be 64 bits when you move to 64-bit pointers.  The array indexing
question can be handled by using long rather than int (or a new indexing
typedef); sure some code will have to be rewritten if int-size /= pointer
size, but code will have to be rewritten anyways if you go to 64-bit
pointers, and this is the only option that gives us all the "normal" sizes
(8,16,32,64) without adding another basic type.

--mike