What's the difference between "int" and "int_fast16_t"?

c integer c99 portability c89

10,996

Solution 1

int_fast16_t is guaranteed to be the fastest int with a size of at least 16 bits. int has no guarantee of its size except that:

 sizeof(char) = 1 and sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long).

And that it can hold the range of -32767 to +32767.

(7.20.1.3p2) "The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N."

Solution 2

int is a "most efficient type" in speed/size - but that is not specified by per the C spec. It must be 16 or more bits.

int_fast16_t is most efficient type in speed with at least the range of a 16 bit int.

Example: A given platform may have decided that int should be 32-bit for many reasons, not only speed. The same system may find a different type is fastest for 16-bit integers.

Example: In a 64-bit machine, where one would expect to have int as 64-bit, a compiler may use a mode with 32-bit int compilation for compatibility. In this mode, int_fast16_t could be 64-bit as that is natively the fastest width for it avoids alignment issues, etc.

Solution 3

As I understand it, the C specification says that type int is supposed to be the most efficient type on target platform that contains at least 16 bits.

Here's what the standard actually says about int: (N1570 draft, section 6.2.5, paragraph 5):

A "plain" int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

The reference to INT_MIN and INT_MAX is perhaps slightly misleading; those values are chosen based on the characteristics of type int, not the other way around.

And the phrase "the natural size" is also slightly misleading. Depending on the target architecture, there may not be just one "natural" size for an integer type.

Elsewhere, the standard says that INT_MIN must be at most -32767, and INT_MAX must be at least +32767, which implies that int is at least 16 bits.

Here's what the standard says about int_fast16_t (7.20.1.3):

Each of the following types designates an integer type that is usually fastest to operate with among all integer types that have at least the specified width.

with a footnote:

The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements.

The requirements for int and int_fast16_t are similar but not identical -- and they're similarly vague.

In practice, the size of int is often chosen based on criteria other than "the natural size" -- or that phrase is interpreted for convenience. Often the size of int for a new architecture is chosen to match the size for an existing architecture, to minimize the difficulty of porting code. And there's a fairly strong motivation to make int no wider than 32 bits, so that the types char, short, and int can cover sizes of 8, 16, and 32 bits. On 64-bit systems, particularly x86-64, the "natural" size is probably 64 bits, but most C compilers make int 32 bits rather than 64 (and some compilers even make long just 32 bits).

The choice of the underlying type for int_fast16_t is, I suspect, less dependent on such considerations, since any code that uses it is explicitly asking for a fast 16-bit signed integer type. A lot of existing code makes assumptions about the characteristics of int that go beyond what the standard guarantees, and compiler developers have to cater to such code if they want their compilers to be used.

Solution 4

From the C99 rationale 7.8 Format conversion of integer types <inttypes.h> (document that accompanies with Standard), emphasis mine:

C89 specifies that the language should support four signed and unsigned integer data types, char, short, int and long, but places very little requirement on their size other than that int and short be at least 16 bits and long be at least as long as int and not smaller than 32 bits. For 16-bit systems, most implementations assign 8, 16, 16 and 32 bits to char, short, int, and long, respectively. For 32-bit systems, the common practice is to assign 8, 16, 32 and 32 bits to these types. This difference in int size can create some problems for users who migrate from one system to another which assigns different sizes to integer types, because Standard C’s integer promotion rule can produce silent changes unexpectedly. The need for defining an extended integer type increased with the introduction of 64-bit systems.

The purpose of <inttypes.h> is to provide a set of integer types whose definitions are consistent across machines and independent of operating systems and other implementation idiosyncrasies. It defines, via typedef, integer types of various sizes. Implementations are free to typedef them as Standard C integer types or extensions that they support. Consistent use of this header will greatly increase the portability of a user’s program across platforms.

The main difference between int and int_fast16_t is that the latter is likely to be free of these "implementation idiosyncrasies". You may think of it as something like:

I don't care about current OS/implementation "politics" of int size. Just give me whatever the fastest signed integer type with at least 16 bits is.

Solution 5

The difference is that the fast types are allowed to be wider than their counterparts (without fast) for efficiency/optimization purposes. But the C standard by no means guarantees they are actually faster.

C11, 7.20.1.3 Fastest minimum-width integer types

1 Each of the following types designates an integer type that is usually fastest 262) to operate with among all integer types that have at least the speciﬁed width.

2 The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.

262) The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements.

Another difference is that fast and least types are required types whereas other exact width types are optional:

3 The following types are required: int_fast8_t int_fast16_t int_fast32_t int_fast64_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t All other types of this form are optional.

View more solutions

10,996

Author by

something_clever

I spend my days writing system software in C++ and annoying my coworkers with my Rust evangelism. Otherwise, my life can be explained mostly as music, guitar, video games, stand-up paddle boarding, and Waffles the Goldendoodle.

Updated on June 06, 2022

Comments

something_clever almost 2 years
As I understand it, the C specification says that type int is supposed to be the most efficient type on target platform that contains at least 16 bits.

Isn't that exactly what the C99 definition of int_fast16_t is too?

Maybe they put it in there just for consistency, since the other int_fastXX_t are needed?

Update

To summarize discussion below:
- My question was wrong in many ways. The C standard does not specify bitness for int. It gives a range [-32767,32767] that it must contain.
- I realize at first most people would say, "but that range implies at least 16-bits!" But C doesn't require two's-compliment storage of integers. If they had said "16-bit", there may be some platforms that have 1-bit parity, 1-bit sign, and 14-bit magnitude that would still being "meeting the standard", but not satisfy that range.
- The standard does not say anything about int being the most efficient type. Aside from size requirements above, int can be decided by the compiler developer based on whatever criteria they deem most important. (speed, size, backward compatibility, etc)
- On the other hand, int_fast16_t is like providing a hint to the compiler that it should use a type that is optimum for performance, possibly at the expense of any other tradeoff.
- Likewise, int_least16_t would tell the compiler to use the smallest type that's >= 16-bits, even if it would be slower. Good for preserving space in large arrays and stuff.
Example: MSVC on x86-64 has a 32-bit int, even on 64-bit systems. MS chose to do this because too many people assumed int would always be exactly 32-bits, and so a lot of ABIs would break. However, it's possible that int_fast32_t would be a 64-bit number if 64-bit values were faster on x86-64. (Which I don't think is actually the case, but it just demonstrates the point)
Olivier Poulin almost 9 years

Instant downvote? @NathanOliver is correct in his statement. int in C's size depends on the system, although it usually is 4 bytes, it can have a higher minimum. int_fast16_t is always going to have at least 4 bytes, no matter what.
something_clever almost 9 years

Your statement about the relative sizes of the types is correct, but you're wrong about there not being minimum sizes. The C standard says "char" must be at least 8 bits, "short" at least 16, "int" at least 16, and "long" at least 32
Olivier Poulin almost 9 years

int doesn't need to have a minimum of 16 bits, thats dependant on the processor, it could have a minimum of 32 bits, which makes it different from int_fast16_t
ElderBug almost 9 years

@OlivierPoulin int DOES need to have a minimum of 16 bits. It's in the C standard.
Persixty almost 9 years

It by no means guarantees they are actually faster. But they must not be slower.
something_clever almost 9 years

This seems to make the most sense... So you're saying that "int" may not be selected for speed, but some kind of space/time tradeoff that the compiler developer makes for the platform, whereas int_fast16_t is like you saying, "I don't care about space, I want it fast"? Seems like the right answer...
NathanOliver almost 9 years

@ElderBug I can't find anything on it with calling out 16 bits but it does have a specified range that is 16 bits. I amended my answer.
P.P almost 9 years

@DanAllen The standard simply gives the flexibility to choose the underlying types for these. I don't think it mandates it shouldn't slower. Of course, compilers won't delibarately do that. If an implementation chooses some type for int_fast8_t and it turns out to be slower than int8_t, are you suggesting it violates any requirements from the standard?
ElderBug almost 9 years

And how would you implement an integer that satisfy this range but doesn't need to be 16 bits ? It needs to be 16 bits, thus this answer doesn't answer the question.
something_clever almost 9 years

@NathanOliver Strike that, notice you already changed your comment.
NathanOliver almost 9 years

@ElderBug I get that. I am just calling it out as it is in the standard.
chux - Reinstate Monica almost 9 years

@ask_me_about_loom Another example: In C, int/unsigned have a special property over other narrower types due to "integer promotions". This features has many impacts aside from speed/size including undefined behavior for narrower unsigned types experiencing overflow. So making int the fastest has many code repercussions. So much code assumes 32-bit int that going to 64-bit int may have subtle negative effects.
something_clever almost 9 years

@OlivierPoulin Yes... 32 bits is larger than 16-bits, so a platform that has a 32-bit int would still be following the C standard... We're not talking about the platform-minimum, we're talking about the C standard. The C standard says that every platform that has a conformant C implementation must have an "int" that is at least 16-bits wide.
Keith Thompson almost 9 years

Thank you for that first upvote. Did you really have time to read all that in 24 seconds?
Keith Thompson almost 9 years

The C standard does not contain the phrase "most efficient type", nor does it explicitly say anything about the efficiency of type int (or rather of operations on type int).
NathanOliver almost 9 years

@ask_me_about_loom Where? All I can find is a range requirement. I realize that it translates to 16 bits as that is the size of the range but I can't find it saying 16 bits. If it doesn't say it then I shouldn't in my answer.
something_clever almost 9 years

Awesome explanation: Excerpts from the C standard followed by actual examples... I really couldn't ask for better. Thanks!
chux - Reinstate Monica almost 9 years

@Keith Thompson C has little efficiency (if any) guarantees either in speed or size. My "most efficient type" is from OP's post and is attempting to steer the idea of "efficiency" from a single dimensional issue (speed) to many things including speed, size, compatibility - of which int tries to satisfy. int_fast16_t is per spec intended to be a fast data type holding at least 16-bits.
something_clever almost 9 years

@NathanOliver By specifying a range, they are necessarily specifying a minimum size. Just because they didn't say the words doesn't mean the implication isn't there. It would be mathematically impossible in a base-2 number system to represent [-32767,32767] with anything less than 16 bits, and C is not portable to anything that isn't a base-2 number system.
Kevin almost 9 years

@ask_me: The C standard does not mandate the use of two's complement, so 16 bits may not be sufficient on some really weird architectures.
something_clever almost 9 years

@chux Indeed, I fear I was thinking a little bit one-dimensionally about the issue. It makes sense that they created these "fast" types to literally say, "screw other tradeoffs, I want speed"
Keith Thompson almost 9 years

Yes, the OP used the phrase "most efficient type", and implies that that's what the standard says int should be. In fact the OP is mistaken on that point, and you didn't correct the OP's error in your answer.
something_clever almost 9 years

@Kevin I appreciate the 2c, but notice we've all been using the word "minimum" here. 16-bits is the minimum for an "int". Yeah, an "int" could be implemented as a 17-bit "sign-mantissa-parity" and still be C-conformant. Nobody's arguing against that, we're just saying that a 15-bit "int" would not be compliant.
Kevin almost 9 years

@ask_me_about_loom: But if the standard said "16-bit minimum," then a 16-bit sign-mantissa implementation would be legal even if it didn't match the range requirements. That's why the range is specified and that's why the range is the only correct way to describe what the standard actually says.
chux - Reinstate Monica almost 9 years

@ask_me_about_loom Not for me, but you may want to leave this good question unaccepted for a day or so. It really gets to the heart of integer aspects of C and I am sure many good insights could be posted and applied. One could write a small book about it even.
something_clever almost 9 years

@Kevin Holy hell, you're right! I suppose there is a way that a type could have 16-bits but still not be able to hold that range! Whoa! Mind blown! I've always wondered why they give the range, not just say "16 bits". This is an EXCELLENT point!
Persixty almost 9 years

I think then it describes them as 'fastest' we are to take them as just that. It doesn't define fastest. However on reflection I withdraw the word 'must' and would put in 'should'. The specification allows for some operations to be faster and others slower but in practice that's not how architectures tend to work.
something_clever almost 9 years

@chux Agreed. C really is one of those languages that is "a week to learn, a lifetime to master". The subtleties of its type system never cease to amaze, haha.
haccks almost 9 years

@ask_me_about_loom; There are other ways around saying thanks here.
Eric Towers almost 9 years

@ask_me_about_loom: In particular on an old Cray that I programmed, the internal integer representation was signed magnitude, so a 16 bit signed integer type could only hold the range specified by the standard. Signed magnitude also has negative zero, so a conformant implementation has to deal with two kinds of compare-with-zero. Additionally, C has been ported to non-binary architectures. It's a stupid stunt, but it's been done.