Are the fixed width integer types guaranteed to be typedefs for the standard built in types?

Question

Are the types from <cstdint> (like e.g. int16_t, uint_fast64_t, int_least8_t) guaranteed to be typedefs for one of the built in types like short, unsigned long etc.?

Or is an implementation allowed to use types that are non of the usual built in ones to implement the fixed width types?

Answer 1

No, at least not for types intN_t. These types are guaranteed to have two’s complement representation (as per C99 7.18.1.1 which C++11 and C++14 reference). And standard integer types don't have to be two's complement.

C11 also has important change over C99 (which is actually just bugfix), emphasizing the point above:

7.20.1.1/3:

However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names.

Answer 2

These are specified by the C standard (and incorporated by reference by the C++ standard), which requires each to be a typedef for a signed integer type or unsigned integer type, as the case may be.

signed integer type is in turn defined by the core language to consist of the standard signed integer types (which are signed char, short int, int, long int and long long int) and any implementation-defined extended signed integer types.

Similarly, unsigned integer type is defined by the core language to consist of the standard unsigned integer types (which are unsigned char, unsigned short int, unsigned int, unsigned long int and unsigned long long int) and any implementation-defined extended unsigned integer types corresponding to the extended signed integer types.

In short, each of those typedefs may be one of the usual built-in types or an implementation-defined extended integer type. Most compilers do not support extended integer types, so on those compilers they must be built-in types.

Answer 3

I have a draft version of the C99 spec in front of me and a draft of the C++14 spec as well. Since these are drafts, this information might be incorrect, but I believe that the wording is the same in the final version.

In the C++14 spec, §18.4.1 has this to say about <cstdint>:

namespace std {
   typedef signed-integer-type int8_t; // optional
   typedef signed-integer-type int16_t; // optional
   typedef signed-integer-type int32_t; // optional
   typedef signed-integer-type int64_t; // optional

   [ etc. ]
}

It then says

The header defines all functions, types, and macros the same as 7.18 in the C standard.

I went to the draft C99 standard, §7.18, and saw nothing that required the types defined to actually be aliases for built-in types like int, long int, etc. It just said that if these types exist, they have to meet certain constraints about their ranges, sizes, and memory layouts.

Overall, I strongly suspect that the answer is "no," but if I'm mistaken, I'm interested to see where I misread the spec. :-)

Hope this helps!