long long/64bit integers

[Thomas M. Breuel]

| 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 size of "int", "long", etc. in C has always been up to the
implementor.  Different C compilers on the same hardware have
frequently provided different sizes for "int" among themselves.

| The Answer
| 
|      The overwhelming concerns are to break as few  programs
| as  possible,  and  to  have  one source base, not two.

No, that must not be the overwhelming concern. Programs that depend on
the size of "int" or "long", in particular, programs that depend on
those types having fewer than some specified number of bits, are
already unportable and will already not work on a large number
of machines.

Now, specific implementations of C may want to optimize specific
features: acceptability of unportable programs, speed, space, etc.
But, again, in C, that's up to the implementor, not a language
committee, to decide.

| 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.

If the running of unportable program is the primary concern for a
particular implementation of C, the implementor should make pointers
the same size as integers, since there are many more unportable
programs that assume that sizeof(int)==sizeof(char*) than there are
programs that assume sizeof(int)<=4.

| We must not change the sizes of datatypes.

There is nothing to "change", since the sizes of datatype have
never been specified in the first place (except for some lower
bounds).

What does make sense is to require compiler vendors to provide
standard header files that define standard type names for objects
with given minimum precision. For examples, the following will
be correct for many (but not all) implementations on 32bit 
workstations:

	/* integer types with at least the stated precision */

	typedef int2 signed char;
	...
	typedef int8 signed char;
	typedef int9 short;
	typedef int16 short;
	typedef int17 long;
	...
	typedef int32 long;
	typedef int33 long long; /* if provided by the compiler */
	...
	typedef int64 long long;

	/* floating point types with at least the stated precision */

	typedef float single_float;
	typedef double double_float;
	typedef double double extended_float;  /* if provided */

(For code that depends on the exact number of bits or bytes in such a
type, it is still necessary to check this number in the program.)

In fact, there are some common header files for this purpose already,
but it may make sense to rethink whether something more appropriate
for numerical applications should be suggested by NCEG. 

Personally, I prefer to use my own typedefs in my programs in those few
cases where I really depend on the size of a datatype.

In summary, there is nothing wrong if specific compiler vendors want
to support specific sizes of integers and pointers in order to make
old, unportable code work easily on new architectures. But to have
this practice mandated or even recommended by any standard seems to me
like a bad idea, and it punishes those people who have written programs
that conform to the current C standard.

					Thomas.

PS: I doubt that the ANSI committee would even look at any proposal
that would try to fix the sizes of integer data types.