Re: [bug-gnulib] localtime_r thread-safe?

[Bruno Haible]

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