CODEWITHSUNDEEP
c++language-lawyer
Baum mit Augen
Baum mit Augen

Reputation: 50053

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

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?

Upvotes: 8

Views: 1051

Answers (4)

Anton Savin
Anton Savin

Reputation: 41301

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.

Upvotes: 4

T.C.
T.C.

Reputation: 137330

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.

Upvotes: 2

templatetypedef
templatetypedef

Reputation: 372784

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!

Upvotes: 2

gnasher729
gnasher729

Reputation: 52538

From the C++ standard: "There may also be implementation-defined extended signed integer types. The standard and extended signed integer types are collectively called signed integer types. ". (I think there is a similar line about extended unsigned integer types) Nothing is said how you would use these extended integer types, they are obviously non-portable and implementation defined.

However, int16_t etc. can be typedefs for extended integer types.

Upvotes: 1

Related Questions