OK, so you're nitpicking grammar. (And given your writing, this is
rather "bold" of you.) So, yes, shall we clarify instead that one "can"
but "must not". It violates the standard; it is a serious application
error. When one steps off a cliff, nature does not raise an error flag
and put you back safely on the ground; that doesn't mean it was a good
idea. (Nor, for that matter, that physics is not well supported by nature.)
As Chris said, Pthreads is far more than "a library", because it cannot
run on top of or as part of a "generic ISO C" or "traditional BSD/SVR
UNIX" -- it places additional stringent requirements for thread-safety
on compiler, runtime, and OS.
Still, you are correct in the implication that there are constraints and
limitations placed by the structure of the language beyond the aspects
of ISO C that POSIX could extend or "profile". Some things (e.g.,
portable lock-free/wait-free constructs) could be enabled only by
"Pthreads" is not an implementation, or even an ABI. It's a source-level
API standard. And, no, we very definitely did not "missed[sic] to check
the obvious things". There is a specifically defined error code for
pthread_cond_wait() to report this condition IF an implementation
chooses to spend the time to detect it. (Unfortunately, POSIX/UNIX error
granularity is not exactly "overly expressive", so it's one of several
possible interpretations of EINVAL.)
Those who wanted to be sure Pthreads supported the greatest possible
runtime performance did not want the standard to be bogged down with
overhead for handholding bad programs. So detection of any error that is
strictly an avoidable application bug was intended to be optional.
Yeah, just like most anything worthwhile or useful is hard. Learning to
speak a language, read music, play piano, design user interfaces...
It's not about being easy, it's about mastering the skills.