With the attached patches, the boot time returned by read_utmp() is stable across 'sudo date MMDDhhmm' invocations. On Linux distros, I found these files to be touched after boot: /var/lib/systemd/ra
Now that I've implemented this method in gnulib's 'readutmp' module and built coreutils with that, I see that it does not work "very well" at all. I have a VM running in VirtualBox, that I booted 6 d
I would take caution if not including a NULL. A natural thing to want to do is print a string, and C-based routines usually expect a terminating NULL. Also, if you initialize the struct, then the all
In most application areas, it is not a problem if strings cannot contain NUL bytes, and thus the C type 'char *' with its NUL terminator is well usable. In areas where strings with embedded NUL bytes
Hi Eli, Thanks for your answers. Well, it's a trade-off regarding the test efforts. I don't want to spend time, testing things on 5 different Windows VMs. Testing things with 3 different Windows tool
That's reasonable for systems where accurate timestamps are not important and where time_t width mismatches would just get in the way. However, if this is the expected approach, I suggest having a st
* Sam James: No, I expect users to run them in time-shifted VMs or containers. Wrong dates are better than no ability to run anything at all. And whoever can recompile to switch to time64 can just re
Hi. In trying to keep gawk up to date with gnulib, I find that there are several recent changes that break compilation. I'm using Ubuntu 22.04. In the files dfa.h, localeinfo.h, malloc/dynarray.h, an
It sync with gnulib version b29d62dfa with the following change: -- diff --git a/stdlib/canonicalize.c b/stdlib/canonicalize.c index 04fe95253f..c8f085b779 100644 -- a/stdlib/canonicalize.c +++ b/std
It sync with gnulib version bbaba6ce5 with the following difference require fix a glibc build: -- stdlib/canonicalize.c +++ lib/canonicalize-lgpl.c @@ -52,7 +52,6 @@ -# define FUNC_REALPATH_WORKS 1 (
It sync with gnulib version d9c121346 with the following difference require fix a glibc build: -- ../../gnulib/gnulib-lib/lib/canonicalize-lgpl.c +++ stdlib/canonicalize.c @@ -46,7 +46,7 @@ -# define
Same here. I really wish we could had more time to put into CI runners. I would like to point out that debugging using a CI like Travis is absolutely tedious and might take a lot of time. Docker-base
Just FYI, gawk's dfa.c is now in sync w/Gnulib's. There are still some problems on Vax/VMS. I suspect it's environmental but will let you know if not. Thanks! Arnold
Paul, Thanks for this. I will work on reducing the differences between what's in Gnulib and what's in gawk. Vax/VMS is dead as a commercial system, true. But it remains alive as a hobbyist system, es
Normally I'd agree, but if Arnold cares about VAX/VMS and if we want Gnulib dfa.c to match Gawk dfa.c, then in this particular case it makes some sense to support 32-bit-only platforms, as it's easy
Hi Arnold, Gnulib now assumes that the C compiler supports 'long long' [1]. VMS on Vax is end-of-life for more than 7 years now [2], and the other CPUs on which VMS is running (alpha, ia64, x86_64)[2
Hi. The gentleman who maintains the gawk port for VMS reports that he can get dfa.c to compile on Vax/VMS, but that he gets failues when trying to use it to compile regular expressions. The Vax/VMS C
On macOS, as far as I can see, everything works as expected without it. So not sure if it's actually needed? Note that /dev/kvm is for linux and does not exist on macOS. Unless we identify specific d
First of all I'm using Linux 5.0.17 & glibc-2.29-15 so as far as I'm aware accept4 exists and fully works and gnulib shouldn't be replacing it at all. I don't understand why it's being replaced. But
I see two patches that went into gnulib overnight. I have now tried compiling hivex with gnulib at commit 34881aff4043, and that seems to have fixed the problem, thanks all. Rich. -- Richard Jones, V