> > 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
I believe the criterion for adding a library to our list of "known thread safe libraries" must be that the libraries are both thread safe -and- reentrant. My $.02. Bill
