{"id":5059,"date":"2021-11-20T00:01:16","date_gmt":"2021-11-20T08:01:16","guid":{"rendered":"https:\/\/c-for-dummies.com\/blog\/?p=5059"},"modified":"2021-11-13T10:47:02","modified_gmt":"2021-11-13T18:47:02","slug":"all-those-_t-data-types","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=5059","title":{"rendered":"All Those _t<\/em> Data Types"},"content":{"rendered":"

You see them often if you code in C: time_t<\/em>, size_t<\/em>, and other _t<\/em> data types, usually specific to some function or library. The C gurus have a method to their madness when it comes to naming these variables. The _t<\/em> stands for something. It’s very consistent on purpose.
\n
\nThe _t<\/em> implies a typedef<\/em>, a defined data type. The typedef<\/em> is based on an existing type. Here are the basic C language data types:<\/p>\n

char
\nint
\nfloat
\ndouble<\/em><\/p>\n

Qualifiers applied to the basic types include short<\/em>, long<\/em>, signed<\/em>, unsigned<\/em>.<\/p>\n

Also included as data types are void<\/em> and _Bool<\/em>, though for the _t<\/em> typedefs, the four basic ones plus a few of the qualifiers are used.<\/p>\n

The question is: Why bother?<\/em><\/p>\n

The reason is compatibility and consistency between architectures.<\/p>\n

Not matter how a library or operating system measures the time, in C you use the time_t<\/em> data type to declare a time value. Years ago, this value may have been a 16-bit integer. Then it became a 32-bit integer to deal with the Y2K problem. For Y36\/Y38 problem, it might be a 64-bit integer on some systems. Still, no matter what the underlying mechanics, you code compiles providing you use the time_t<\/em> data type when dealing with time values.<\/p>\n

The question of the underlying type does play a role when using a placeholder.<\/p>\n

For example, the sizeof<\/em> operator returns a size_t<\/em> value – essentially a quantity of bytes. As I do so often in my code, I use the %d<\/code> placeholder to output a size_t<\/em> value. That is, until the compiler reminds me:<\/p>\n

<\/p>\n

warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]\r\n        printf(\"The array is %d bytes in size\\n\",sizeof(array));\r\n                             ~~                  ^~~~~~~~~~~~~\r\n                             %lu\r\n1 warning generated.<\/pre>\n
<\/code><\/p>\n
Years ago, the %d<\/code> placeholder worked! But the underlying format is unsigned long<\/em>, and clang<\/em> is nice enough to show me where the mistake took place, which argument is referenced, and which conversion characters to use. It’s all too often that I rely upon compiler warnings like this to discover which placeholder to use.<\/p>\n
Oh, by the way, the %zu<\/code> placeholder can always be used to output a size_t<\/em> value, whether it’s changed in the future or not.<\/p>\n
When you don’t know the underlying data type for a _t<\/em> typedef<\/em>, you can go spelunking in the header files to locate the specific definition. Sometimes you might be lucky and find the typedef<\/em> immediately in the header file. With modern compilers, however, the typedef<\/em> is most likely included in another header file, often in a subdirectory.<\/p>\n
For example, time_t<\/em> is found in the \/usr\/include\/bits\/types\/time_t.h<\/code> file in one of my Linux distros. But in this file, it’s included in the \/usr\/include\/bits\/types.h<\/code> header file, where its definition is related to defined constants in even other header files. Ugh.<\/p>\n
No, it’s best to just use the typedef<\/em> variable as intended. And, unfortunately, if the man<\/em> page doesn’t explain which placeholder to use, best-guess it and wait for the warning to appear. This approach is disappointing, but it works.<\/p>\n","protected":false},"excerpt":{"rendered":"
No, the C gurus did not add _t<\/code> just to make declaring variables more difficult to type. Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-5059","post","type-post","status-publish","format-standard","hentry","category-main"],"_links":{"self":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/5059","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5059"}],"version-history":[{"count":5,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/5059\/revisions"}],"predecessor-version":[{"id":5067,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/5059\/revisions\/5067"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5059"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5059"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5059"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}