Rule 50. POSIX (POS)

I really think  POSIX issues should be a separate document.   C is used on things that are not POSIX

Oh, heck, I can defend leaving it here for now ... there's a reasonably strong affiliation between the C and POSIX communities, and until the POSIX section expands into a whole book-length topic by itself (if ever), it seems simpler to just keep it where it is now.

POSIX interfaces do serve as a guidline for extending Standard C even on non-POSIX platforms.

Would a rule saying "Mutexes should be locked and unlocked in the same level of abstraction" (eg similar to MEM00-C. Allocate and free memory in the same module, at the same level of abstraction be useful?

I think keeping a POSIX section is worthwhile since it does influence the direction of the C standard and occassionally changes the semantics and behavior of functions defined in the C standard. It is useful to know this type of information.

A rule saying "pthread_cancel() should not be used" may be useful. I personally have come across a lot of code using pthread_cancel() to terminate a thread and rarely did I not find problems with that code. Even using pthread_cleanup_push() and/or pthread_setcancelstate() to control what happens when the thread is canceled or when we can cancel the thread tends to lead to disaster. There is always something missing in the thread cleanup handler, or something wasn't included in the non-cancelable block of code that should have been. I view pthread_cancel() as a ticking time bomb; even if the code is implemented correctly today, someone will break it later on.

The primary problem I have with using pthread_cleanup_push() and pthread_cleanup_pop() is that you are, perhaps unknowingly, making the assumption that all of the functions you call within the thread were written to be cancellable. For instance lets say that the thread calls some kind of parser routine which ultimately calls read(). If the implementor of this function didn't expect the thread it is running to be canceled, then they probably didn't protect against it. If pthread_cancel() is called while the parser is calling read() than any resources inside that parser routine will be leaked. Another problem with these routines I've seen deals with mutexes — perhaps we have a cleanup routine which will ensure that we call pthread_mutex_unlock(). But what happens if we didn't actually still have that mutex locked when we hit our cancelation point? According to POSIX you can only unlock a mutex owned (locked) by that thread, therefore nothing bad happens, just the call to pthread_mutex_unlock() returns -1 and sets errno to EPERM. Now what happens to the same code on Linux? Well on at least some version of Linux the mutex will be unlocked regardless of which thread actually owned it.

Using pthread_setcancelstate() has its limitations as well. I'll avoid the details for now...

There are other means to get the desired effect of pthread_cancel() that typically are safer, however these techniques typically are less generic (i.e. the proper solution may depend on the type of "work" performed by the thread).

Just noticed that POS33-C was deleted completely on July 10, 2020...  Is there any reason? as one of our customers is asking for it. thanks