In 7.24.5.8 (The strtok function) it is mentioned that:
The strtok function is not required to avoid data races with other calls to the strtok function.
An implementation which would like to support applications which call strtok in the presence of threads will face substantial challenges in doing so. The reason is that the standard currently requires that the strtok internal state is shared among all threads, and an application can observe this by calling strtok from several threads with proper synchronization. (The data races cannot be avoided by using atomic operations inside strtok alone because the buffer is written to within strtok and read outside of it, and the read access is not atomic.)
The Solaris implementation of strtok appears to be non-conforming because it is implemented with thread-local state:
The strtok() function is safe to use in multithreaded applications because it saves its internal state in a thread-specific data area. [Source]
POSIX suggests the possibility of a thread-safe implementation of the function, but does not discuss that strictly conforming programs are able to detect that the hidden internal state has thread storage duration, by calling the strtok function from separate threads with suitable external synchronization.
Rather than coming up with language that covers all existing implementation behavior, we propose to make the strtok function undefined in multi-threaded programs. This is the approach already used for the signal function.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4