Bruno Haible <[EMAIL PROTECTED]> writes: > Since I cannot see how a function can return a pointer and an int > simultaneously,
It can't. If you want the old, incompatible (DCE) localtime_r under HP-UX, you're supposed to link with the DCE library and compile with -D_PTHREADS_DRAFT4. But anyone who wants the DCE localtime_r won't want gnulib localtime_r anyway, so this shouldn't be a problem. > and since I've no idea when _PTHREADS_DRAFT4 is defined, I wouldn't > trust the system's localtime_r function here. Our existing check will already reject any misconfigured build that defines _PTHREADS_DRAFT4 and therefore gets the wrong prototype. So I don't see the danger here. The only problem that I can see is that you need to use the right macros defined to get the system headers to define localtime_r under HP-UX. We should put that into gl_TIME_R, if it isn't there already. >> 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. But GNU Pth uses strictly non-preemptive scheduling, right? So I don't see the problem; surely gnulib localtime_r won't be preempted. (Disclaimer: I've never used GNU Pth.)
