Thread: C Data Types Naming Convention

char, float, and double are standard types. bool is provided by <stdbool.h> (a typedef for _Bool), and int32_t is provided by <stdint.h> if the C implementation happens to define a signed 32-bit integer type with no padding bits. The _t suffix is simply the convention used by the integer types provided by <stdint.h>.

There are very few situations in which a fixed-width integer type, like int32_t, is actually needed. In many cases long will work just as well.

Edit: Sorry, bool is actually a macro that expands to _Bool, rather than a typedef.

"Burdensome and unsightly" seems a bit too harsh. Nor was it "singled out". The standard defines a number of types that end in _t: size_t, ptrdiff_t, atomic_t, wchar_t to name a few.

Why this "inconsistency"? No idea really -- maybe it is consistent, we just don't know what meaning the _t suffix has to the C89/C99/C11 committees. A quick search turned up nothing conclusive, but I really didn't try very hard.

As far as typedef'ing, you can do it, you likely aren't damning your code, though I don't think it really helps in any way either. Especially considering that proper code most likely should be using size_t, and maybe other _t types that don't benefit from typedef'ing away the _t (imagine a type called just size...ugh). But, for the fixed-width integer types, it won't really hurt anything either, unless you're interacting with code that has different definitions of uint8, int32, etc.

As for personal view/opinion
Downsides:
* I generally avoid mere "convenience" typedefs, unless it substantially improves the readability of the code. Complex function pointer definitions might be an example of useful convenience typedefs (I usually use an _f or _fp or similar suffix). Saving me an awkward keystroke or two is never justification for adding even small complexity to my code.
* While the typedef is a small change, it does add some extra maintenance for you, making sure you typedef all the types correctly (when you add a 64-bit type, e.g.), and include the right header in every .c file.
* You may use a third-party library that defines the same types to different things, resulting in conflicts between it and your code.
Conformance to standards, clarity and readability are all extremely important as your project grow in scope, especially when there are multiple people working on a project, and should outweigh decisions that amount to "I'm lazy".

Upsides:
* Avoid having to type awkward _t suffix

Mixed:
* Looks like other standard types which is nice for consistency...but it's actually not a standard type, so that may actually be A Bad Thing.

Originally Posted by Casa

However C11 (and C99) has chosen to differentiate the short and long types and introduce the bool type (curiously not as bool_t).

The reason for bool instead of bool_t may well be because the type is named as such in C++, hence the standard committee might have C code that can also be compiled as C++ code in mind (e.g., for the benefit of some libraries).

Originally Posted by Casa

I also note that there are float_t and double_t types mentioned, but these are then typedefed into float and double in math.h.

The standard does not require that float_t always be a typedef for float or that double_t always be a typedef for double; what they are depends on FLT_EVAL_METHOD. You're looking at implementation detail and then jumping to conclusions.

You expect 100% consistency in a standard designed by committee? Be real. The old saying about a camel being a horse designed by committee applies.

To answer the question though .... Types with the _t prefix are not guaranteed to be supported by all C implementations and, if they are supported, they are declared in standard header files (for example, as a typedef). Types like char, int, short, etc are guaranteed to be supported by any C implementation (i.e. if the implementation claims compliance with a particular version of the C standard, it supports all the basic types specified in that standard).

But even that is not 100% consistent.

The reason for bool being a macro rather than a keyword (as it is in C++) had both political and technical contributors. As did the introduction of wchar_t as a keyword in C++.

Casa, you clearly have no understanding of how standardisation committees work, nor interest in understanding.

My contribution to this thread is therefore over.

Originally Posted by Casa

Just because something was done by a committee, doesn't mean it should be substandard.

Agreed. On the other hand, even for programming languages where there is/was a single person with the final say over the language and standard library design choices, inconsistencies crept in. In the end, the development of programming languages and their associated standard libraries is something of an organic process: if you don't have industry players and myriad of other interested parties as the decision makers (as in a committee), you have them influencing the decision makers, whether by pressure via feedback or the existence of a third party library with conventions that have become de facto standard.

Originally Posted by Casa

More importantly it does not mean that things should not be improved over time.

Easy to say; hard to do when you have to cater to a very wide audience. As nonpuz mentioned in post #5, the standard reserves some names. This is good because it means that a future version of the standard can introduce more names without breaking existing code. The bad part is that the very act of reserving names can mean that existing code suddenly becomes problematic, and of course the more rules there are, the harder it is to remember what is reserved and what is not.

So, int32 might sound like a better idea than int32_t, and maybe it is. But when introducing it, there would be the concern that existing programs use int32, especially if they use them differently from what the standard would state (e.g., as the name of a variable). There might also be consideration that perhaps it was known that some existing libraries declared int32_t in the way that inspired the standard to introduce this, in which case keeping to an existing convention would be better. Furthermore, requiring the _t suffix in order for a name starting with int to be reserved would be a plus to make it less likely for a reserved name to be declared (contrast with say, the restrictions imposed by <ctypes.h> such that isfriendly is reserved).