From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: "long long" for 64 bits
Summary: Let's separate the issues of 64 bit ints in 32/64 bit modes
Date: 13 Apr 92 15:53:37 GMT
Organization: Xanadu Operating Company

In article <1992Apr02.223220.7151@convex.com> allison@convex.com (Brian Allison) writes:
>It seems to me that the "scheme" of using "long long" for 64-bit ints is
>already a de facto standard, so your request should be for the new kids on the
>64-bit block to adopt "long long" as well.

A couple of people have said this.  It's only half right, and since it
appears to be contributing to the flamage I want to clarify.

There are two COMPLETELY DISTINCT problems being intermixed in this
discussion of 64-bit data types.

The first is how to add 64 bit integers to a 32-bit C compiler
on an architecture that either implements them in hardware or can
conveniently provide 64 bit operations from the compiler. Clearly, in an
established compiler with many customers, changing the size of long would
break a large amount of code, all of the libraries, and much of the
operating system, which is probably a good reason not to do so.  For this
reason, a new type has been added in those compilers that support 64 bit
integers.  While you can argue about what it should be called, 'long long'
has become the de facto standard name for this type in those C compilers
whose 'long' was 32 bits. The only really interesting question is should it
be aligned to a 32 or 64 bit boundary.  The answer depends on whether you
need to build 32-bit structures that will be forwards-compatible with a
64-bit environment.

If you find it worth your time, feel free to continue arguing about the
name, but it probably isn't very productive.

The second, more interesting issue is what to do about C datatypes in a
PURE 64-bit machine (i.e. a NEW machine with a NEW compiler).  Such machines
have 64-bit pointers and four interesting integer sizes: 8/16/32/64 bits.
The ANSI/ISO-consistent way to name these is char/short/int/long.

The problem with this mapping is that it breaks a large amount of code.
Lots of code (perhaps even the majority of code out there today) makes one
or more of the following assumptions:

	sizof(long) == sizeof(void *)	- arise in lots of procedure
	sizof(int) == sizeof(void *)	  interfaces

	sizof(int) == sizeof(long)	- arises in lots and lots of
					  places, of which several, such as
					  constant expressions and printfs
					  are difficult to automatically
					  locate.

The 64 bit environment question is therefore confounded by two incompatible
goals:

	1. Be consistent with the standards (not just for C, but for POSIX,
	   SVID, OSF, X/Open, etc. etc. etc.
	
	2. Be consistent with the programs.

The problem gets even more confusing, because some vendors would like to
built 32-bit and 64-bit interfaces that are close to bit for bit compaitble
where possible.  Consider the problem of an operating system on a 64 bit
SPARC that supports a file system with 64 bit file sizes.  How do you tell
the 32-bit compatibility-mode program what the file size is when it only
has a 32-bit field in which to receive the answer?  How do you avoid
teaching EVERY PART of the operating system how to deal with both 32- and
64-bit applications? [With UNIX, you can't, but it's a long discussion to
prove it.]  There are a lot of people in the industry who, with good
reason, are DESPARATE to contain the engineering costs of building 64-bit
software environments.

From a pedantic perspective, you can tell a customer that a program which
depends on the size relationship is simply wrong; and you can feel smug
afterwords about the sanctity of your position.

Unfortunately the customer may as a result feel smug about their right to
take their business elsewhere.

In any case, I believe that it will help the discussion content to separate
the two issues:

	1. 64 bit integer in existing 32-bit compiler
	2. Datatype size choices in a 64-bit compiler.

Hope that helps clarify what the issues really are, at least.


Jonathan Shapiro
Newsgroups: comp.lang.c