In C, what meaning, if any does the t at the end of integer types like uint8_t and int32_t have? Where did it originate? Why wasn't the type just called int32?


4 Answers 4


Because all identifiers ending with _t are reserved for future additional types.

The int32_t family of types was added in the C99 standard, so they used the reserved names to avoid conflict with already existing software.

You can find a nice overview of reserved names in the glibc documentation.

Since Microsoft is not the C standards committee, they are right in not using the _t family of names, opting for the unreserved INT32 instead.

  • For what standard C doesn't reserve ending in _t, POSIX reserves the rest.
    – Blrfl
    Jul 8, 2015 at 0:44
  • I'm pretty sure INT32 predated int32_t. May 25, 2016 at 16:29
  • @StevenBurnap That may be correct, I don't know. But that is not really important. Important is the fact that _t types are reserved, and the fact that int32_t is in the standard while INT32 is not. May 26, 2016 at 6:02
  • My point is just that Microsoft chose INT32 because there was no standard alternative when it did so and now has to keep it for backwards compatibility. May 26, 2016 at 13:48

At the time the C99 Standard was ratified, there already existed countless C programs that used int32 as an identifier. On platforms where both int and long were 32 bits, some of that pre-existing code would have defined int32 as int and some as long (the latter allows compatibility with platforms where int is 16 bits but long is 32; the former allows compatibility with platforms where int is 32 bits but long is 64). While it might have made sense for compilers to allow "int" and "long" to by synonymous on platforms where they're both 32 bits and have matching representations, in which case the "new" int32 type could compatible with both, the Standard doesn't allow for that.

Code written for a platform where int32 is known to be synonymous with int can use int* and int32* interchangeably. Code written for a platform where int32 is known to be synonymous with long can use int32* and long* interchangeably. Even on platforms where both int and long have identical representations, however, the Standard requires platforms squawk if an attempt is made to convert an int* to long* or vice versa without a cast.

Further, even on platforms where int and long have the same representation, casting an int* to a long* is not required to yield a pointer that's usable as a long*; the current maintainers of gcc believe that since the Standard doesn't require that such a cast work, their compiler should generate code where such casts sometimes fail.

Thus, if C99 had used int32 rather than int32_t, it would have had to break code that defines that identifier as int and expects it to be synonymous with int, or code that defines that defines that identifier as long and expects it to be synonymous with long.


The _t data types are typedef types in the stdint.h header, while int is a built-in fundamental data type to C. The _t datatypes are only available if stdint.h exists. The fundamental data types like int, however, are guaranteed to exist.

Basically, it really doesn't mean much of anything. It's just how C decided to name things.


size_t is read as 'size type'

_t usually means type, and sometimes typedef.

Why wasn't the type just called int32

So it could be distinguished from a built in type, stdint.h is supposed to choose the proper built in type to be the given size depending on the platform. N.b. some compilers int32_t aliases a compiler specific notation like i_32 or something similar.

Microsoft took a different approach and their standard is based on #defines, with values like INT32, DWORD, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.