[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] localtime_r thread-safe?
From: |
Ralf Wildenhues |
Subject: |
Re: [bug-gnulib] localtime_r thread-safe? |
Date: |
Thu, 4 May 2006 09:38:10 +0200 |
User-agent: |
Mutt/1.5.11 |
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