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

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Wed, May 03, 2006 at 10:39:06PM CEST:
> 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

Yes, but the reason this fails is because some extension isn't turned
on (ia64-hp-hpux11.23):

| configure:53740: checking whether localtime_r is compatible with its POSIX 
signature
| configure:53764: cc -c -g  conftest.c >&5
| "conftest.c", line 178: warning #2047-D: incompatible redefinition of macro 
"fnmatch" (declared at line 170)
|   #define fnmatch posix_fnmatch
|           ^
| 
| "conftest.c", line 390: error #2020: identifier "localtime_r" is undefined
|         struct tm * (*ptr) (time_t const *, struct tm *) = localtime_r;
|                                                            ^
| 
| 1 error detected in the compilation of "conftest.c".

and not because the signature is wrong.  (Excerpt from a gnulib-all-test
done a couple of months ago; no, I never found the time to analyze more
than a few issues of it; it would be really helpful if gnulib-tool could
actually create a dummy-all test on its own, including all *tests
modules, without the need for lots of manual tweaking.)

> > 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:

> 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.

Unless you have other evidence that the function is broken, this isn't
really a reason to not trust the function, right?  I mean, hey, glibc
headers at one point looked ugly, too.

Cheers,
Ralf