Sixty Four Bit Integer

[Seebs]

There's a type in Java called <long> that is essentially a 64-bit in-
teger. Is there a type <long> in C that is also a 64-bit integer?
Sometimes!

Or, if there isn't, is there a type by some other name that is a 64-
bit integer?

Sometimes!

In C89, there may or may not be any 64-bit integer types.

In C99, there has to be at least one integer type which has at least 64
bits, and there may be types which have more. The "long long" type has
to have at least 64 bits, and the "int64_t" type has to have exactly 64
bytes or not exist.

In either, any integer type (including char) MAY be 64 or more bits, although
it's unusual for any type shorter than long to be 64 bits.

-s

 

[KevinSimonson]

There's a type in Java called <long> that is essentially a 64-bit in-
teger. Is there a type <long> in C that is also a 64-bit integer?
Or, if there isn't, is there a type by some other name that is a 64-
bit integer?

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

 

[Ben Pfaff]

There's a type in Java called <long> that is essentially a 64-bit in-
teger. Is there a type <long> in C that is also a 64-bit integer?

In C99, you can use "long long" to get an integer that is at
least 64 bits long.

 

[Chris McDonald]

In C99, you can use "long long" to get an integer that is at
least 64 bits long.

In C99 you may also include <stdint.h> and then use the datatype int64_t

(here we go again....)

 

[Ben Pfaff]

In C99 you may also include <stdint.h> and then use the datatype int64_t

Seebs' parallel reply is pretty comprehensive.

 

[Seebs]

Please let me take this opportunity to welcome you back to the
comp.lang.c world of typographical error.
Thanks!

I'd guess int64_t eight bytes.

It's 64 bits exactly or it doesn't exist. Or the compiler is broken.

There's also int_least64_t, which is 64 or more, and which I think has to
exist because you can't have a conforming implementation without a 64-bit
type.

Note that this may or may not be eight "bytes", because C tends to call
the character type a "byte" even if it's over 8 bits.

-s

 

[Seebs]

A conforming C99 implementation may have an exact 64-bit
signed integer and not supply int64_t, if it does not
implement two's complement.

True. And in fact, I'd forgotten that. However, I can salvage this by
pointing out that I didn't say that if a 64-bit type existed, it must be
available through the name int64_t -- only that if int64_t existed, it
must be 64 bits exactly. ... But even my attempt to salvage it is wrong,
because (at least as of C99 TC3), the implementation MUST define int64_t
if it has a suitable type (2's complement, 64 bit exactly).

-s

 

[Chris McDonald]

There's also int_least64_t, which is 64 or more, and which I think has to
exist because you can't have a conforming implementation without a 64-bit
type.

Thanks Seebs;
by your above reasoning, would int64_t have to exist, as well?

 

[Peter Nilsson]

It's 64 bits exactly or it doesn't exist. Or the compiler
is broken.

A conforming C99 implementation may have an exact 64-bit
signed integer and not supply int64_t, if it does not
implement two's complement.

 

[James Kuyper]

Seebs wrote:
....

There's also int_least64_t, which is 64 or more, and which I think has to
exist because you can't have a conforming implementation without a 64-bit
type.

Correct. And don't forget int_fast64_t, which is also required to exist;
it is the fastest type with at least 64 bits.

 

[Seebs]

Thanks Seebs;
by your above reasoning, would int64_t have to exist, as well?

No. As noted elsewhere in the thread, you can't define int64_t unless
you have a two's complement 64-bit type. Furthermore, it's certainly
permissible to have an implementation where, say, the only types are 128
bits, or even 8/16/32/128. (char, short, int and long, long long -- that
would be conforming, so far as I can tell).

-s

 

[James Kuyper]

Thanks Seebs;
by your above reasoning, would int64_t have to exist, as well?

The exact-sized types are required to use 2's complement, and are
optional. If long long is a 64-bit 1's complement type, int64_t is not
required to exist.

The least-sized and fast-sized types are not required to use 2's
complement, and are mandatory for sizes 8, 16, 32, and 64.

 

[Ben Bacarisse]

Thanks Seebs;
by your above reasoning, would int64_t have to exist, as well?

No. The phrase "you can't have a conforming implementation without a
64-bit type" is a slight over-statement of the requirement. There
must be an integer type that with at least 64 bits because of the
limits set on the allowable values for LLONG_MAX and LLONG_MIN, but
you could meet these with a type that was "wider" than 64 bits.

int64_t (if it exists) must have exactly 64 bits. It must also use
2's complement arithmetic and have no padding bits so there are three
reasons why it might not be provided by a conforming C99
implementation.

 

[Michael Foukarakis]

No.  As noted elsewhere in the thread, you can't define int64_t unless
you have a two's complement 64-bit type.  Furthermore, it's certainly
permissible to have an implementation where, say, the only types are 128
bits, or even 8/16/32/128. (char, short, int and long, long long -- that
would be conforming, so far as I can tell).

Permissible, yes. Realistic?

(hint: if the answer's no, the OP doesn't need to have the standard
quoted to him.)

 

[Seebs]

Permissible, yes. Realistic?

(hint: if the answer's no, the OP doesn't need to have the standard
quoted to him.)

I would hesitate to speculate on what will or won't be "realistic". I've
used a chip which had native 128-bit words, on which it was fairly easy
to do 128-bit math, and fairly easy to do 32-bit math (on vectors, even),
but not nearly as easy or convenient to do 64-bit math. It wouldn't
be impossible for a compiler vendor to decide to make long-long a 128-bit
type there to ensure that the C types cover the whole range...

My experience has been that trying too hard to guess what's "realistic"
tends to lead to sadness a decade or so later. In this case, we were
discussing the question of what requirements the standard imposes on a
particular type; the standard seemed more relevant to this question to me
than my speculations as to what chip vendors will do in the future -- or
may have already done, and I just haven't run into it.

-s

 

[James Kuyper]

Permissible, yes. Realistic?

(hint: if the answer's no, the OP doesn't need to have the standard
quoted to him.)

I would not recommend wasting too much time worrying about what's
"realistic". Reality has far too many surprises in it; this year's
"unrealistic" may easily the "de-facto standard" a few years down the
road - or on machines that you're not even aware of. Understand what the
standard allows; write most of your code so it only depends upon things
that the standard actually guarantees. Keep code which actually depends
upon implementation-specific details like that to an absolute minimum,
and isolated as much as possible from the rest of your code.

 

[Charlton Wilbur]

S> My experience has been that trying too hard to guess what's
S> "realistic" tends to lead to sadness a decade or so later.

That long? I've seen it happen in a matter of *weeks*.

Charlton

 

[Seebs]

S> My experience has been that trying too hard to guess what's
S> "realistic" tends to lead to sadness a decade or so later.

That long? I've seen it happen in a matter of *weeks*.

Oh, certainly. It *can* happen extremely quickly.

But I've almost never seen it NOT happen within a decade.

Ten years ago, "let's just download a high-quality movie in real-time
without noticably affecting our home network performance" was not realistic.
Now it's sufficiently commonplace that I didn't even think to CHECK the
stated bandwidth requirements for the service; I just wanted to see whether
they had Mac support.

For that matter, ten years ago, I was having fierce arguments with my
friends about how Mac OS would be improved by the inclusion of a command
line, and they told me it was unrealistic because there was no possible
market or benefit.

I have forgotten, and stumbled across by accident, a thing the size of one
of my fingernails (and not a thumbnail, either), which has 4GB of non-volatile
storage. That's certainly not realistic either.

And yes, all of these things affect design decisions. We used to have a
horrible time in tech support for a server system because BIND was designed
around the assumption that you should abort if you couldn't allocate enough
memory to cache all the DNS entries you'd found; after all, it wasn't
realistic to imagine there being so many DNS entries that this was a problem.
For a brief period in the late 90s, though, the internet namespace was
growing dramatically faster than available memory was, and we had to walk
a lot of customers through elaborate setups and thousands of dollars of extra
memory... But that's okay, because it couldn't possibly have happened,
because it wasn't *realistic*. (A conclusion the dot-com bust supports,
I suppose.)

-s

 

[Phil Carmody]

The exact-sized types are required to use 2's complement, and are
optional. If long long is a 64-bit 1's complement type, int64_t is not
required to exist.

The least-sized and fast-sized types are not required to use 2's
complement, and are mandatory for sizes 8, 16, 32, and 64.

Nit - they don't have to use 2's complement, they have to
provide 2's complement semantics. They can use an abacus
behind the scenes, if need be.

Phil

 

[Keith Thompson]

Nit - they don't have to use 2's complement, they have to
provide 2's complement semantics. They can use an abacus
behind the scenes, if need be.

I don't see the difference between using 2's complement and using 2's
complement semantics. Does it matter, as far as the language is
concerned, what kind of hardware is used to implement arithmetic?