> This is a particularly interesting case as Mark is pretty adamant
> that strtok() and gethostbyname() should be thread-safe and the fact
> that it isn't on most platforms doesn't persuade him to use
> strtok_r() or gethostbyname_r() if available. (Not that I disagree
> with him here - these *should* be thread-safe calls.)
That is clearly wishful thinking -- strtok/gethostbyname are
legacy, non-reentrant APIs according to POSIX/SUSv3.
The problem with these APIs is that it is impossible to make
them reentrant. Yes, you can solve half of the problem by
using thread-local storage in the legacy APIs. But then they
are still not reentrant, just thread-safe.
For portable applications, there is only one choice -- use
those interfaces which are marked as reentrant and don't
assume that suddenly all vendors will provide thread-safe
implementations of non-reentrant APIs. That simply won't
happen.
What's his problem with the reentrant APIs? Is the cost of
transition too painful for him?
- Sascha
