Integer Types

[Ben Bacarisse]

CBFalconer said:


Why not long int?

That's a good question but not a good answer!

Presumably you pose it as a question rather than offering it as an
answer (and you did so in another message directly to the OP) because
you know that long int is rarely a 64-bit integer even when it could
be.

This is an area where C90 is of little help. Short of implementing
your own integer arithmetic, long long is probably the most portable
was to go if you need a type with at least 64 bits. It is one of the
most widely implemented parts of C99.

<snip>

 

[Eric Sosman]

Well then what should the 64-bit type be on a machine that can support it?

His next question will probably be "What's the best
way to declare and define global variables and functions?"

(That's just a likelihood, not a certainty. A sequence
whose first two terms are 1.1 and 1.4 may well continue with
1.7, but it may turn out that the sequence rule is more
intricate than a simple arithmetic progression.)

 

[Ben Bacarisse]

64 bit.

I think you mean "int", don't you? I am assuming this is advocacy for
64 bit ints again.

Integers usually hold counts of things, or index numbers. Not always, of
course, but you have to be pretty artificial to write a program where most
integers don't end up evaluating array indices before output.
This is true even of chars, if you think about it. A char will be used as an
index into a glyph table before you can see it. It is also true of most
enumerated types.The type will be held as a table somewhere which gives
characteristics associated with it.

Since most of the time we are counting things in the computer's memory, it
follows that the generic int type should be large enough to index that
memory.

Why does the fact that I am counting the number of

-- spots on a die
-- direct children of a tree node
-- digits in a phone number
-- bits in an int
-- levels in an AVL tree
-- cards in a poker hand
-- ...

mean that I must need to index all available storage? Conversely, why
should my integers be limited by what memory locations I can index?
The number of

-- permutations of a string
-- bridge deals
-- IPv6 addresses
-- Turing machines with n states
-- ...

is not connected to the number of addressable locations. Of course, I
may not want to count these one by one, but the point is that indexing
and counting are different operations.

If ints are 64 bits, and are fast, which they ought to be because for
technical reasons the integer registers are usually the same width as the
address registers, then you hardly need any other type, except for a few
special circumstances.

This has not always been true. Are you sure this will be true for the
future of such a language? C is about 30 year old.

However this policy is not currently understood. 64 bit vendors are
declaring int as 32 bits to retain binary compatibility with 32 bit
processors. This is leading to a zoo of types, most wickedly size_t.

Wicked?

 

[Flash Gordon]

64 bit.

Yeeesss, the 64 bit type on a machine that can support it should be 64 bits.

Integers usually hold counts of things, or index numbers. Not always, of
course, but you have to be pretty artificial to write a program where most
integers don't end up evaluating array indices before output.

You keep claiming this without real evidence and despite may people
pointing out that they do lots of work on software where this is not the
case.

This is true even of chars, if you think about it. A char will be used as an
index into a glyph table before you can see it. It is also true of most
enumerated types.The type will be held as a table somewhere which gives
characteristics associated with it.

So you want 64 bit characters as well do you? In any case, a lot of
software is client/server, where the client is on a different machine
with a different environment, so it is not necessarily relevant. A lot
more software is embedded with no character display of any type.

Since most of the time we are counting things in the computer's memory, it
follows that the generic int type should be large enough to index that
memory.

That would only be true if you were counting things in computer memory.
If you are counting pennies in a back account it doesn't matter how big
memory is.

If ints are 64 bits, and are fast, which they ought to be because for
technical reasons the integer registers are usually the same width as the
address registers, then you hardly need any other type, except for a few
special circumstances.

Even if the arithmetic is fast you still slow down getting the data
on/off the processor.

However this policy is not currently understood. 64 bit vendors are
declaring int as 32 bits to retain binary compatibility with 32 bit
processors.

More likely you failing to understand the very good reasons of companies
like Intel.

This is leading to a zoo of types, most wickedly size_t.

size_t has existed since at least 1989.

 

[Flash Gordon]

64 bit.

Yeeesss, the 64 bit type on a machine that can support it should be 64 bits.

Integers usually hold counts of things, or index numbers. Not always, of
course, but you have to be pretty artificial to write a program where most
integers don't end up evaluating array indices before output.

You keep claiming this without real evidence and despite may people
pointing out that they do lots of work on software where this is not the
case.

This is true even of chars, if you think about it. A char will be used as an
index into a glyph table before you can see it. It is also true of most
enumerated types.The type will be held as a table somewhere which gives
characteristics associated with it.

So you want 64 bit characters as well do you? In any case, a lot of
software is client/server, where the client is on a different machine
with a different environment, so it is not necessarily relevant. A lot
more software is embedded with no character display of any type.

Since most of the time we are counting things in the computer's memory, it
follows that the generic int type should be large enough to index that
memory.

That would only be true if you were counting things in computer memory.
If you are counting pennies in a back account it doesn't matter how big
memory is.

If ints are 64 bits, and are fast, which they ought to be because for
technical reasons the integer registers are usually the same width as the
address registers, then you hardly need any other type, except for a few
special circumstances.

Even if the arithmetic is fast you still slow down getting the data
on/off the processor.

However this policy is not currently understood. 64 bit vendors are
declaring int as 32 bits to retain binary compatibility with 32 bit
processors.

More likely you failing to understand the very good reasons of companies
like Intel.

This is leading to a zoo of types, most wickedly size_t.

size_t has existed since at least 1989.

 

[Ian Collins]

Presumably you pose it as a question rather than offering it as an
answer (and you did so in another message directly to the OP) because
you know that long int is rarely a 64-bit integer even when it could
be.

It is on just about every 64 bit Unix/Linux system, so "rarely" isn't
appropriate.

 

[Keith Thompson]

Keith Thompson said:



Okay, but it seems to me that we already had the equivalent of
intleast8_t, intleast16_t, and intleast32_t in C90, didn't we?

Not quite. intleast32_t could be any of short, int, or long. If you
require an integer type that's at least 32 bits wide while being no
larger than necessary (ideally exactly 32 bits, but more is ok if no
32-bit type is available), then C90 didn't provide a straightforward
way to get that. You could use a bunch of #if directives, but frankly
that's too much work -- and different applications would do it
differently. In C99, the implementer has done all that work for you
in a way that's as portable as C99 itself. (Aye, there's the rub.)

As for intfast32_t, there's no way at all to define that in pure
portable C90; C99 requires the implementer to do that work as well.

I'm a bit disappointed that C99 chose to make the exact-width types
the "default", in some sense. I'd prefer to be able to specify a
range of values that must be supported, and let the compiler pick a
type for me. But perhaps for the kinds of problems for which C is
used, exact-width tpyes are needed more often.

 

[Flash Gordon]

Keith Thompson said:



Okay, but it seems to me that we already had the equivalent of
intleast8_t, intleast16_t, and intleast32_t in C90, didn't we?

No, you didn't. The least types are the *smallest* types meeting the
relevant requirements. short might not be the smallest types with at
least 16 bits (you could have CHAR_BIT==16 and sizeof(short)==2).

I know, I know - they aren't going to back down now, ten years after
the event!

I doubt they will.

 

[Keith Thompson]

Keith Thompson said:

Ok, but that's what the intfastN_t and intleastN_t types are for.

Okay, but it seems to me that we already had the equivalent of
intleast8_t, intleast16_t, and intleast32_t in C90, didn't we?
[...]

I think the C90 intention was effectively:

signed char = intleast8_t
short = intleast16_t
int = intfast16_t
long = intmax_t (must be 32 bits or more)

If so, that intention was never stated in the standard. signed char
could be int_least8_t, but none of the others are guaranteed or even
implied by C90.

 

[Ben Bacarisse]

It is on just about every 64 bit Unix/Linux system, so "rarely" isn't
appropriate.

I knew there would be trouble! What's the right word? Not often
enough that one can assume this in portable C90 code?

 

[James Kuyper]

Keith Thompson said:



Okay, but it seems to me that we already had the equivalent of
intleast8_t, intleast16_t, and intleast32_t in C90, didn't we?

Roughly, but only a few of the size-named types had C90 equivalents; for
most of them no C90 type was exactly the right solution.

As a general rule, I would use (if I had the choice, which is currently
seldom the case) signed char, short, int, and long if I would otherwise
characterize the types I was looking for as int_least8_t, int_least16_t,
int_fast16_t, and int_least32_t; but I would do so only because it saves
typing. Conceptually, I consider the size-named types a superior idea,
but poorly named.

 

[CBFalconer]

That's a good question but not a good answer!

Richard seems to enjoy wasting bandwidth on very little. The
answer is simply that a long int is not guaranteed to hold 64
bits. A long long is. No other type is guaranteed to exist and
hold 64 bits.

 

[James Kuyper]

Richard seems to enjoy wasting bandwidth on very little. The
answer is simply that a long int is not guaranteed to hold 64
bits. A long long is. No other type is guaranteed to exist and
hold 64 bits.

I presume that you mean that long long is guaranteed to hold 64 bits,
but is allowed to hold more than 64. It's certainly not required to be
exactly 64 bits.

With that understanding, there are three other types named by the
standard that are guaranteed to exist and to hold at least 64 bits:
int_least64_t, int_fast64_t, and intmax_t. While any one of them might
be a typedef for long long, they are not required to be - they are
permitted to be typedefs for any other basic type, with 'long' being the
likeliest alternative, or they could be implementation-specific types.

 

[Phil Carmody]

It is on just about every 64 bit Unix/Linux system, so "rarely" isn't
appropriate.

What value do you get when Unix is divided by Linux?

;-D

Phil

 

[Sjouke Burry]

What value do you get when Unix is divided by Linux?

;-D

Phil

Division of two NAN's is undefined.

 

[CBFalconer]

.... snip ...

I presume that you mean that long long is guaranteed to hold 64
bits, but is allowed to hold more than 64. It's certainly not
required to be exactly 64 bits.

With that understanding, there are three other types named by
the standard that are guaranteed to exist and to hold at least
64 bits: int_least64_t, int_fast64_t, and intmax_t. While any
one of them might be a typedef for long long, they are not
required to be - they are permitted to be typedefs for any other
basic type, with 'long' being the likeliest alternative, or they
could be implementation-specific types.

I see the following in the C standard. Note the 'All'.

[#3] The following types are required:

int_fast8_t uint_fast8_t
int_fast16_t uint_fast16_t
int_fast32_t uint_fast32_t
int_fast64_t uint_fast64_t

All other types of this form are optional.

I think some description of the meaning of 'All' is required.

 

[luserXtrog]

What value do you get when Unix is divided by Linux?

;-D

Finally, an excuse to brag about Postscript!

GS>36#Unix 36#Linux div =
0.0395701

;{>

 

[Peter Nilsson]

CBFalconer said:

The answer is simply that a long int is not guaranteed
to hold 64 bits.  A long long is.  No other [integer]
type is guaranteed to exist and hold 64 bits.

...as far as I'm aware /none/ of my users has a C99
implementation...

None of my users /need/ a C99 implementation.

 

[Ian Collins]

What value do you get when Unix is divided by Linux?

;-D

The same as when C is divided by C++.....

 

[Keith Thompson]

I see the following in the C standard. Note the 'All'.

[#3] The following types are required:

int_fast8_t uint_fast8_t
int_fast16_t uint_fast16_t
int_fast32_t uint_fast32_t
int_fast64_t uint_fast64_t

All other types of this form are optional.

I think some description of the meaning of 'All' is required.

Really? It seems perfectly obvious to me. The phrase "this form"
refers to types whose names are int_fastN_t or uint_fastN_t, where N
is replaced by an unsuffixed decimal integer constant. A program
cannot assume either than int_fast42_t is defined, or that it isn't.