CERT
Skip to end of metadata
Go to start of metadata

This appendix contains guidelines for functions that are defined as part of the POSIX family of standards but are not included in the C Standard. These rules and recommendations are not part of the core standard because they do not apply in all C language applications and because they represent an incomplete set. The intent of providing these guidelines is to demonstrate how rules and recommendations for other standards or specific implementations may be integrated with the core C recommendations.

Information for Editors
In order to have a new guideline automatically listed above be sure to label it pos and rule.

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

POS30-CHighProbableMedium

P12

L1

POS33-CLowProbableLow

P6

L2

POS34-CHighUnlikelyMedium

P6

L2

POS35-CHighLikelyMedium

P18

L1

POS36-CHighProbableMedium

P12

L1

POS37-CHighProbableLow

P18

L1

POS38-CMediumUnlikelyMedium

P4

L3

POS39-CMediumLikelyLow

P18

L1

POS44-CLowProbableLow

P6

L2

POS47-CMediumProbableLow

P12

L1

POS48-CMediumProbableHigh

P4

L3

POS49-CMediumProbableMedium

P8

L2

POS50-CMediumProbableHigh

P4

L3

POS51-CLowProbableMedium

P4

L3

POS52-CLowProbableHigh

P2

L3

POS53-CMediumProbableHigh

P4

L3

POS54-CHighLikelyMedium

P18

L1

Related Rules and Recommendations


6 Comments

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

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

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

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

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

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