5 ms·

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

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?

flohofwoe 4y ago
> 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.
- never_inline 4y ago
  > 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.
  - flohofwoe 4y ago
    Yes, but this sort of problem exists with other 'standard APIs' too which change much more frequently than POSIX.
- taeric 4y ago
  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.
- deleted 4y ago
  [deleted]
- saagarjha 4y ago
  > 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.
  - pjmlp 4y ago
    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.
    - saagarjha 4y ago
      The world’s most popular compilers target POSIX platforms. Being compliant with that is very important to them.
      - pjmlp 4y ago
        Except they seem quite happy to only care about what ISO requires from them.
        saagarjha 4y ago
        To be clear we are talking about the same GCC and Clang here, right?
kzrdude 4y ago
Gotcha is a good description of the whole thing and I would suggest it is not a concern for real code.
pengaru 4y ago
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.

flohofwoe 4y ago

> 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.

never_inline 4y ago
> 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.
- flohofwoe 4y ago
  Yes, but this sort of problem exists with other 'standard APIs' too which change much more frequently than POSIX.
taeric 4y ago
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.
deleted 4y ago
[deleted]
saagarjha 4y ago
> 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.
- pjmlp 4y ago
  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.
  - saagarjha 4y ago
    The world’s most popular compilers target POSIX platforms. Being compliant with that is very important to them.
    - pjmlp 4y ago
      Except they seem quite happy to only care about what ISO requires from them.
      - saagarjha 4y ago
        To be clear we are talking about the same GCC and Clang here, right?

kzrdude 4y ago

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

pengaru 4y ago

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.