What does the “t” in int32_t signify?
https://softwareengineering.stackexchange.com/questions/288968
-
09-10-2020 - |
Pergunta
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
?
Solução
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.
Note:
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.
Outras dicas
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.