It's "enforced" to the extent that future versions of the standard will feel free to define new types which end with _t without worrying about breaking existing code. If you defined your own uint32_t type and the new standard's uint32_t type stomps on it, well, you were (theoretically) warned.

The trailing _t is reserved, and I didn't know that for many years. I learned of it only after an interview candidate pointed it out as a gotcha in my question prompt. They got bonus points, and I learned something. I wonder why compilers or static analyzers don't complain about these things more often?

> I wonder why compilers or static analyzers don't complain about these things more often?

Because it's not the C compiler's business to care about POSIX.

POSIX and the C standard are different things. If you're writing code against the Windows APIs, POSIX isn't relevant for instance, and you need to be more concerned about colliding with type names or defines from the Windows API headers, and those are all over the place anyway.

...and besides: that rule is entirely pointless in reality, either your type names collide with POSIX types from headers you are including (in that case you're getting a compiler error anyway), or they don't collide, and in that case all is good.

There is one more case, for your list at the end. The names could start colliding when you get to add interaction with a posix system.

That is, most of the point of that was for some standards to give a "follow these rules, and you will have an easier time integrating with this standard if that is in your plans."

Obviously, if you have no plans to head to posix, they accomplish nothing for you. Similarly, not following the rules doesn't prevent that direction, just adds some extra work. Potentially.

> besides: that rule is entirely pointless in reality

I think it means: a library author cannot name some type epoch_t, because POSIX may introduce an epoch_t in the next revision, and suddenly some code may fail to compile.

Yes, but this sort of problem exists with other 'standard APIs' too which change much more frequently than POSIX.

> Because it's not the C compiler's business to care about POSIX.

It is when people write POSIX-compliant code and their compiler doesn’t let them.

ISO C compliance doesn't have any POSIX compliance requirements, as ISO C compilers target more platforms than UNIX like clones.

It is the POSIX platform owners business to ensure POSIX compliance on their own C compiler.

The world’s most popular compilers target POSIX platforms. Being compliant with that is very important to them.

Except they seem quite happy to only care about what ISO requires from them.

To be clear we are talking about the same GCC and Clang here, right?

The _t suffix is so ergonomic for typedefs this is one area of POSIX I simply ignore, because my types are usually prefixed with a namespace POSIX won't ever collide with anyways.

Gotcha is a good description of the whole thing and I would suggest it is not a concern for real code.

Effectively, every C library needs to do that, usually reserving some prefix.

It’s just a way to state “if you’re using this API/library, be prepared that future versions may introduce additional symbols matching these patterns, and/or that the current version may define undocumented symbols matching these patterns”. You then have the choice to take care to not define symbols conflicting with that.

The alternative would be for libraries to just add arbitrary new symbols, with no way for client code to proactively prevent conflicts.

Yes _t is very attractive to programmers as a suffix to indicate a type, and I've flagged in the past to people that they shouldn't technically do that - usually to be met with utter indifference