3 ms·

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 i

by qsort 4y ago

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.

mytailorisrich 4y ago
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.
- qsort 4y ago
  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 https://en.cppreference.com/w/c/language/identifier
  - Someone 4y ago
    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.
- alerighi 4y ago
  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.

by qsort 4y ago

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.

mytailorisrich 4y ago

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.

qsort 4y ago
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 https://en.cppreference.com/w/c/language/identifier
- Someone 4y ago
  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.
alerighi 4y ago
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.