Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 1003.1c™-1995 IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)

Copyright © 1996 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #39
Topic: thread - safety Relevant Clauses: 2.3.9, Page 32, Lines 754-761

The referenced paragraph says that all POSIX.1 and ISO C functions except those enumerated within the paragraph shall be thread safe. Why are the functions getenv(), localeconv(), and strerror() not in the list of exceptions? Their absence implies that they SHALL be thread safe, yet their definitions each state that the object pointed to by their return value MAY be overwritten by a subsequent call to the same function.

If this is the case, implementations cannot provide thread safety through internal synchronization because the return object as seen by one thread may be corrupted by another thread AFTER the function returns to the first thread, but before the first thread is finished utilizing or copying the object. Although it is quite possible for an implementation to provide these in a thread safe fashion using thread specific data with destructors, the function definitions allow non-thread safe behavior, directly contradicting this paragraph.

These 3 functions fall into the same general category as asctime() or ttyname(), and should be in this list. In the future, thread safe versions of these functions should be included in the standard (getenv_r, localeconv_r, strerror_r). Suggested Correction: Add getenv(), localeconv(), and strerror() to the list of functions that need not be thread safe.

Interpretation Response
The standard is clear that getenv(), localeconv(), and strerror() must be thread-safe. A conforming implementation shall satisfy this condition. However, concerns have been raised in the interpretation committee that this was not the intent of the working and balloting groups. This is being referred to the sponsor for consideration.

Rationale for Interpretation
It appears that the standard has a defect - the working group and the balloting group seems to have missed these three functions. Note, that the standard states that all POSIX.1 and ISO C be functions be thread safe but for a list of exceptions that have _r equivalents. These functions should have been part of the list of exceptions. A getenv_r() function should clearly be added. Likewise requirements for localeconv_r() and strerror_r() should added for systems that provide localeconv() and strerror(). (Note that these ANSI C functions are not required by IEEE Std 1003.1-1996.)