You need more old-junk computers in your collection. I've already got too many, thanks. I assume that this constitutes a bug in the Tru64 C RTL I'd call it a bug, but strictly speaking POSIX allows
Thanks for the prompt response. You need more old-junk computers in your collection. I assume so. If HAVE_DECL_STRTOLL is back in the generated config.h file, then that's good enough for me. Strictly
I think it's a gnulib bug. We don't run into compilers lacking 'long long' often nowadays, so I'm not surprised the bug is there. I pushed the following patch to gnuliband am cc'ing to bug-gnulib. Do
When in doubt, don't do it, I always say. Sounds safer (though still less clear than "= 0", I claim). Yeah, it's harmless. I didn't remember seeing it in the original (right-order) arg list, so I was
Thanks, I fixed that typo. (No need for the "(int)" type cast around here, either.) The cast is needed on some platforms, and shouldn't hurt on VMS. "bool" has that property in C99, as well as in the
Oooh, I don't think that I'd do that. If the victim specifies a VMS directory, like, say, "dkc0:[sms]", for TMPDIR, then a ":" test on the last character will fail. As usual, everything's complicated
+ sprintf (tmpl + dlen, &"/%.*sXXXXXX"[!add_slash], pfx, (int) plen); Around here, I get fewer %SYSTEM-F-ACCVIO run-time complaints if I reorder the arguments: sprintf (tmpl + dlen, &"/%.*sXXXXXX"[!a
Come to think of it, the code can be simplified; there's no need for a while loop there. I installed the following patch instead. diff --git a/ChangeLog b/ChangeLog index 4d73a26..9b0cccd 100644 -- a
Thanks for the heads up. I pushed this but have not tested under VMS, so please give it a try. -- ChangeLog | 12 ++++++++++++ lib/tmpdir.c | 22 ++++++++++++++++-- 2 files changed, 28 insertions(+), 6
While trying to get Wget to work on VMS (again), I ran into a problem with tmpdir.c:path_search(). The Wget maintainer denied responsibility, and suggested that I direct my complaint here. -- lib/tmp
Thanks, for that problem I installed the following gnulib patch. There's no need for HAVE_STDLIB_H these days, as we're assuming C89 or better now for that sort of thing. * lib/getcwd-lgpl.c: Include
Excellent. This is the truncated exponential backoff method I was referring to previously (albeit a little less general). It's probably worth a comment that this may introduce a total delay of up to:
Interesting, but problematic on mingw: unlink() of an open fd is not guaranteed to succeed, and indeed fails on mingw; you can also provoke the failure in some NFS setups. You'd need to add some clea
Playing with the code a bit and testing on various VMs (where the race showed up most probably), it turned out that the multiplier for the nap() delay is not sufficient. Changing it from 1.125 to 3
In looking at the test, I do see some race conditions that could be triggered by high load, or by clocks running at slightly different speeds on a file server versus its client. I fixed the problems
While it may be a kernel bug triggering the ctime issue, it would be best to report that and try to avoid by retrying with another nap() up to some maximum. A more adaptive approach might be better t
Yes, I've seen those repeatedly, over the years, especially in VMs, and more likely when run in parallel with other tests. Here's one thread about it: https://lists.gnu.org/archive/html/bug-gnulib/20
Hi Eric, OK for the argumentation for the POSIXy systems. But for the Windows/mingw libc, I would be more careful. mingw is a moving target (it moves closer towards POSIX over time), and has EINTR. I