A shorter name probably broke someone's code in 1998.

_t acts as a namespace, and that's all namespacing you can get in C.

Calling it just "uint8" could conflict with software which already used it as an identifier, or worse, a macro; on the other hand, names ending with _t are reserved (see for instance https://www.gnu.org/software/libc/manual/html_node/Reserved-...), so they could be used by the standard for these new types.

The convention '_t' is to unambiguously indicate that the name is a type.

Some people also use '_e' for enums, etc.

The _t suffix is reserved for types defined by the standard. Although this is an excess of pedantry, strictly speaking you should not be defining names ending in _t.

By 'the standard' do you mean POSIX? Or has that been added to a C standard?

Either way, in general I'd agree this is an excess of pedantry and I don't really see an issue with using _t for types if that works for you.

I wasn't sure, I just checked.

POSIX reserves everything ending in _t. C99 and later reserve identifiers starting with "int" or "uint" and ending in "_t".

Source: https://en.cppreference.com/w/c/language/identifier

For those wondering: that phrase has to be read as “C99 and later reserve identifiers ((starting with "int" or "uint") and ending in "_t")”, not as “C99 and later reserve identifiers starting with "int" or "uint" and identifiers ending in "_t"”

It’s not as if a program with a variable called interest_rate or ford_model_t would be nonconforming according to the standard.

While this is true, I don't see either a reason to use _t in your code. Since it's your code, you don't have the problem for which the _t suffix was introduced, that is to avoid conflicts that can break other people code. You don't either get any benefit of using the _t suffix, since it's obvious if something is a type or not, especially nowadays (just look at the syntax coloring). You don't even need the _t to distinguish for example between a struct, enum or union definition and it's relative typedef:

    typedef struct MyStruct { ... } MyStruct;

is perfectly valid, and in my opinion better than:

    typedef struct MyStruct_s { ... } MyStruct_t;

Where the suffix _s and _t doesn't add anything useful but only complicate the code for nothing.