Paul Eggert wrote: > I don't know of any hosts that have multithreading and localtime but > lack a working localtime_r.
HP-UX 11.00 with HP/PA. HP-UX 11.23 with IA64. In both cases: checking whether localtime_r is compatible with its POSIX signature... no > The problems that I know of in this area > typically are namespace problems, where the system has a localtime_r > but refuses to let you see it unless you utter the appropriate > mumbojumbo. In this case I'd prefer the bug to be exposed to the > installer (so that they can use the appropriate compiler flags), > rather than worked-around with a replacement involving a global lock, > since the system's localtime_r undoubtedly will be better than our > replacement. The header on HP-UX 11 looks like this: # ifndef _LOCALTIME_R # define _LOCALTIME_R # ifndef _PTHREADS_DRAFT4 extern __struct_tm *localtime_r(const __time_t *, __struct_tm *); # else /* _PTHREADS_DRAFT4 */ extern int localtime_r(const __time_t *, __struct_tm *); # endif /* _PTHREADS_DRAFT4 */ # endif Since I cannot see how a function can return a pointer and an int simultaneously, and since I've no idea when _PTHREADS_DRAFT4 is defined, I wouldn't trust the system's localtime_r function here. > If there's a specific system where this global-lock workaround is > actually needed Any other system where the localtime_r test fails, when GNU Pth is installed. (GNU Pth is a portable multithreading library, even when the system doesn't have POSIX threads.) Bruno