Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lsuc!sq!msb
From: msb@sq.sq.com (Mark Brader)
Subject: Re: 64 bit architectures and C/C++
Message-ID: <1991May6.232116.11401@sq.sq.com>
Summary: a case for "long long"
Organization: SoftQuad Inc., Toronto, Canada
References: <16023@smoke.brl.mil> <1991May2.033545.15051@athena.mit.edu> <16036@smoke.brl.mil>
Date: Mon, 6 May 91 23:21:16 GMT
Lines: 61


> There are numerous CONFORMING ways in
> which additional integer types can be added to C.  "long long" is NOT
> one of these, and a standard-conforming implementation is OBLIGED to
> diagnose the use of "long long", which violates the Constraints of
> X3.159-1989 section 3.5.2.  Therefore "long long" is not a wise way
> to make such an extension.

I disagree.  I think "long long" is a preferable approach.

The Standard does not guarantee that there exists, in a C implement-
ation, any integral type wider than 32 bits.  A programmer wishing
to do arithmetic on integer values exceeding what can be stored in
32 bits has three options:

	(a) use floating point;
	(b) represent each such value using more than one object of some
existing integral type, e.g. using a "bignums package"; or
	(c) use an integral type known to provide the required number of
bits, and never port the program to machines where no such type exists.

Option (a) may not be feasible for a number of reasons, not least of
which is that significance may be lost using floating point -- the
Standard does not guarantee that any floating point type in a C imple-
mentation can hold as many significant digits as a 32-bit integer can.
Option (b) also has significant costs, so the programmer with access to a
suitable machine may choose to accept the portability loss and choose (c).

Now, what would we like to happen if a program that assumed 64-bit
integers existed was ported to a machine where they didn't?  We would
like the compilation to fail, that's what!  Suppose that the implementation
defines long to be 64 bits; then, to force such a failure, the programmer
would have to take some explicit action, like

	assert (LONG_MAX >= 0777777777777777777777);

On the other hand, suppose that the implementation defines a separate
"long long" type for 64-bit integers.  Then when the user compiles the
program on the 64-bit machine, they get:

	cc: warning: "long long" is an extension and not portable

and, assuming a reasonable quality of implementation, they can eliminate
this message with a cc option if desired.  And if they do try to port,
they get a fatal error in compilation.

This behavior seems exactly right to me.

Now, I am *not* saying that an implementation should necessarily make
"long long" its *only* 64-bit integral type.  It'd be wholly reasonable
to define *both* "long" and "long long" as 64 bits.  Just as a programmer
uses "long" whenever more than 16 bits are *required*, although "int" may
be the same as "long", "long long" could be used whenever more than 32
bits are required, although "long" might be the same as "long long".

-- 
Mark Brader            \  "He's suffering from Politicians' Logic."
SoftQuad Inc., Toronto  \ "Something must be done, this is something, therefore
utzoo!sq!msb, msb@sq.com \ we must do it."   -- Lynn & Jay: YES, PRIME MINISTER

This article is in the public domain.