[PATCH 2/2] xstrtol: simplify integer overflow checking

(-) diff --git a/ChangeLog b/ChangeLog index a1896fa7d3..2ea372b0e3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2022-01-16 Paul Eggert + xstrtol: simplify integer overflow checking + * lib/xstrtol.c: Include intprops.h. + (TYPE_SIGNED): Remove, as intprops.h defines

[PATCH 1/2] xstrtoll-tests: use %lld for long long

/ChangeLog @@ -1,3 +1,13 @@ +2022-01-16 Paul Eggert + + xstrtoll-tests: use %lld for long long + * tests/test-xstrtoll.c, tests/test-xstrtoull.c (__spec): + Do not assume long long is 64 bits, or that exact-width + 64-bit types exist. Although these assumption

Re: [PATCH] copy-file-range: work around Linux kernel bug

On 1/16/22 05:37, Pádraig Brady wrote: This looks like the replacement will only be used when the build system uses an older kernel? If so this seems brittle. Consider the case where el7 rpms are being built on central build systems with newer kernels. It doesn't run any code on the newer

Compilations warnings-as-errors when building from git

In Assaf Gordon writes: I'm getting few warnings-as-errors when building the latest version from git (using Debian 10 amd64 with gcc 8.3.0). I wouldn't worry about these. We typically don't bother to pacify older GCC versions as

Re: oset-c++: Avoid compilation error with nvc++ 22.1

On 1/15/22 10:52, Bruno Haible wrote: Note that the compiler defines both __EDG__ and __PGIC__. The former apparently describes the C++ frontend, the latter the code generation phase. Ouch. It's possible that some (but not all?) occurrences of __EDG__ in intprops.h should actually be

Re: [bug-diffutils] bug#53256: Compiling 3.8 with nvhpc 22.1 : malloca.c 64 bits operations with signed and unsigned operands are currently unsupported by __builtin_add_overflow

es support. To work around the bug I installed the attached into Gnulib and this should appear in the next diffutils release. In the meantime you can compile with gcc.From f0b5cdf9a1fdb5c991cf3e1bdffb55e31126dffc Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 14 Jan 2022 18:50:48 -0800 Subje

[PATCH] nstrftime: pacify nvc 22.1 unreachable statement

-14 Paul Eggert + nstrftime: pacify nvc 22.1 unreachable statement + * lib/nstrftime.c (__strftime_internal): + Omit unreachable ‘break;’. + tests: pacify nvc 22.1 unreachable statement * tests/test-sys_wait.h (test_sys_wait_macros): Widen scope

[PATCH] tests: pacify nvc 22.1 unreachable statement

..9113099129 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2022-01-14 Paul Eggert + tests: pacify nvc 22.1 unreachable statement + * tests/test-sys_wait.h (test_sys_wait_macros): + Widen scope of ‘#if 0’ so that there is not an unreachable ‘break;’. + tests: pacify nvc

[PATCH] tests: pacify nvc 22.1 set-but-not-used

a/ChangeLog b/ChangeLog index cf22140d44..5fb16542aa 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2022-01-14 Paul Eggert + tests: pacify nvc 22.1 set-but-not-used + * tests/test-fnmatch.c (main): Don’t set a var without using it. + * tests/test-sched.c (f1): Now extern

[PATCH] copy-file-range: work around Linux kernel bug

hangeLog @@ -1,3 +1,20 @@ +2022-01-14 Paul Eggert + + copy-file-range: work around Linux kernel bug + This workaround is adapted from Coreutils. + * lib/copy-file-range.c [__linux__ && HAVE_COPY_FILE_RANGE]: + Include . + (copy_file_range): Use a

Re: Problems with directory trees "confdir-14B---" and "confdir3"

On 1/11/22 03:43, Peter Dyballa wrote: This way you can draw your own conclusions. Thanks, but I think the problem has been diagnosed (see my previous email). Someone would need to implement the solution, though. I hope that's something you can do

Re: Problems with directory trees "confdir-14B---" and "confdir3"

On 1/9/22 03:10, Peter Dyballa wrote: checking whether getcwd aborts when 4k < cwd_length < 16k... yes and of course the reports about not being able to remove the "confdir-14B---" and "confdir3" directory trees, So, the problem is that the test program creates the deep directories,

[PATCH] backupfile: fix bug when renaming not from wd

--git a/ChangeLog b/ChangeLog index aa3b04035d..33dbeb7bc6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2022-01-10 Paul Eggert + + backupfile: fix bug when renaming not from wd + * lib/backupfile.c (backupfile_internal): Fix bug when DIR_FD + does not specify

Re: Problems with directory trees "confdir-14B---" and "confdir3"

On 1/7/22 14:43, Peter Dyballa wrote: The actual cause seems to be an ability of the MacPorts software (Tcl based) to remove the deep directory structure. I expect that one option is to use GNU coreutils 'rm' instead of MacPorts 'rm'. Coreutils 'rm' should not have the bug you're observing.

Re: Stack module and -Wsign-compare

the attached.From 403968da56573bdbdcab79adabddcdc270e05cc9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 5 Jan 2022 11:37:26 -0800 Subject: [PATCH 1/2] stack: pacify gcc -Wsign-compare * lib/stack.h (_GL_STACK_TYPE): Use idx_t for size too. Suggested by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib

Re: test-strerror_r fails on GNU/Hurd

On 1/2/22 16:28, Bernhard Voelker wrote: 1073741858: that's 2^30 +34 Could it be an address, or part of an address, that is incorrectly treated as an integer? A mistake like that is quite plausible given the "does it return char * or int?" API of strerror_r.

Re: Some generated header files are messed up on Alpine

the portability problem. Also, I emailed a bug report to the BusyBox maintainers <http://lists.busybox.net/pipermail/busybox/2022-January/089400.html>.From 75541c6adaf6fc45541a35d2c8803b9b68f2a7fc Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 1 Jan 2022 15:30:38 -0800 Subject: [PATCH] =?U

[PATCH] maint: fix ‘make update-copyright’ on symlinks

644 => 12 etc/license-notices/LGPL diff --git a/ChangeLog b/ChangeLog index e2f467e75b..28d95dedec 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2022-01-01 Paul Eggert + + maint: fix ‘make update-copyright’ on symlinks + After running ‘make update-copyright’ I n

Re: Infinite recusion in test-timespec_getres.exe

On 12/31/21 04:56, Gisle Vanem wrote: Paul Eggert wrote: On 12/30/21 07:48, Gisle Vanem wrote: -#elif defined HAVE_TIMESPEC_GETRES +#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_

Re: Infinite recusion in test-timespec_getres.exe

On 12/30/21 07:48, Gisle Vanem wrote: -#elif defined HAVE_TIMESPEC_GETRES +#elif defined HAVE_TIMESPEC_GETRES && HAVE_TIMESPEC_GETRES This change has an effect only if there's the equivalent of '#define HAVE_TIMESPEC_GETRES 0' somewhere. How did that happen? If your platform lacks

[PATCH] crypto/sm3-buffer: fix C99 conformance bug

--- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2021-12-30 Paul Eggert + + crypto/sm3-buffer: fix C99 conformance bug + * lib/sm3.c (sm3_process_block): Call varargs macro with enough + arguments. Problem found by IBM XL/C 12.1.0.0 for AIX. + 2021-12-30 Bruno Haible Update

Re: [PATCH] doc: Fix example for all Win32 compiler

If is right, the symbol _WIN32 is really confusing since it doesn't mean one is building for 32-bit Microsoft Windows systems, which is the natural interpretation of that symbol for those who are not already expert in developing for Microsoft Windows.

[PATCH] nstrftime: improve handling of invalid formats

+ lib/nstrftime.c | 14 ++ 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index 74a988abd2..ed9e63b851 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2021-12-28 Paul Eggert + + nstrftime: improve handling of invalid formats

[PATCH 2/2] * lib/gettime-res.c: 1 cs -> 10 ms in comment.

--- lib/gettime-res.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gettime-res.c b/lib/gettime-res.c index 6e9784347..8c3ea1c71 100644 --- a/lib/gettime-res.c +++ b/lib/gettime-res.c @@ -57,7 +57,7 @@ gettime_res (void) /* On some platforms, clock_getres

[PATCH 1/2] * lib/gettime-res.c (gcd): Mark with _GL_ATTRIBUTE_CONST.

--- lib/gettime-res.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gettime-res.c b/lib/gettime-res.c index 0d7f1cfea..6e9784347 100644 --- a/lib/gettime-res.c +++ b/lib/gettime-res.c @@ -21,7 +21,7 @@ #include "timespec.h" -static long int +static long int

Re: [PATCH 3/5] gettime-res: new module

On 12/28/21 13:41, Bruno Haible wrote: We have a 'gcd' module already, that could be used here. I tried that at first, but it was another module dependency and the types weren't quite right so I just did the classical algorithm. (Although, I also like to use metric prefixes where other

Re: [PATCH 1/5] gettime: port better to non-POSIX C2x

On 12/28/21 13:30, Bruno Haible wrote: Isn't this currently a no-op, as all platforms that have timespec_get (namely: glibc, FreeBSD, NetBSD, OpenBSD, macOS, Solaris 11) also have clock_gettime? Yes, it's just future-proofing. Would it make sense to prefer timespec_get over clock_gettime on

[PATCH 4/5] timespec_getres: new module

/timespec_getres create mode 100644 modules/timespec_getres-tests create mode 100644 tests/test-timespec_getres.c diff --git a/ChangeLog b/ChangeLog index 8b25c542b..79739541e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,15 @@ 2021-12-28 Paul Eggert + timespec_getres: new module + * lib

[PATCH 2/5] clock_gettime: improve doc

--- doc/posix-functions/clock_gettime.texi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/posix-functions/clock_gettime.texi b/doc/posix-functions/clock_gettime.texi index 230372d47..93ac4215d 100644 --- a/doc/posix-functions/clock_gettime.texi +++

[PATCH 3/5] gettime-res: new module

insertions(+), 4 deletions(-) create mode 100644 lib/gettime-res.c create mode 100644 modules/gettime-res diff --git a/ChangeLog b/ChangeLog index 23c87e8e1..8b25c542b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2021-12-28 Paul Eggert + gettime-res: new module + * lib

[PATCH 1/5] gettime: port better to non-POSIX C2x

on the gettimeofday module. --- ChangeLog | 10 ++ lib/gettime.c | 2 ++ m4/gettime.m4 | 4 ++-- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5bbedae84..23c87e8e1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2021-12-28 Paul

[PATCH 5/5] clock_getres: document portability issues better

3 files changed, 23 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 79739541e..ac8d1baea 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2021-12-28 Paul Eggert + clock_getres: document portability issues better + * doc/posix-functions

Re: makefile rules

On 12/24/21 09:24, Bruno Haible wrote: It seems to work fine on all platforms I tested: Linux distros, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Solaris, Minix (all with the default 'make'). Thanks for testing, and for the review. I installed the patches with your suggested improvements.

libtextstyle-optional fails ./gnulib-tool --test

The command "./gnulib-tool --test libtextstyle-optional" fails with the last few output lines as follows. I tried going back into the past but didn't find an old Gnulib version where the command worked (though the failure symptoms differed), so I don't think this is purely due to recent Gnulib

Re: makefile rules

ched patch, which adds a couple of @NMD@s that were missed earlier.From 42415d79b8dcfeb761db41a4067fa6a18b0d4912 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 22 Dec 2021 10:57:36 -0800 Subject: [PATCH 1/2] =?UTF-8?q?maint:=20omit=20unnecessary=20=E2=80=98rm?= =?UTF-8?q?=20-f=20$@-t=20$@=E2=80=99?= MIME-Version: 1.0

Re: makefile rules

On 12/21/21 12:23, Jim Meyering wrote: Even with `mv -f` support, one must still either remove $@-t or otherwise ensure that it is writable. The read-only temporary may have been left behind from a preceding, interrupted run of the same rule. Yes, that's the "(though not perfect)" I alluded

Re: makefile rules

On 12/21/21 11:50, Jim Meyering wrote: One must delete $@ and the potential $@-t temporary file in any rule that creates a generated file and marks it (as I prefer always to do) as read-only by using chmod to subtract write permissions. Otherwise, the attempt to redirect to $@-t (when it is

Re: makefile rules

AVE_ALLOCA_H)|g' \ + $(SED_HEADER_END) \ + $(srcdir)/alloca.in.h + $(AM_V_AT)mv -f $@-t $@ else alloca.h: $(top_builddir)/config.status rm -f $@ From 46540554bb4564e2929d5fecdae194701142777d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 21 Dec 2021 10:43:56 -0800 Subje

Re: MKDIR_P invocations

On 12/20/21 01:08, Bruno Haible wrote: @NMD@ $(MKDIR_P) '%reldir%' && \ Although that'd work, it might be a bit of a maintenance hassle. How instead using a new macro $(AUTOMAKE_MKDIR_P) instead of $(MKDIR_P)? AUTOMAKE_MKDIR_P would default to $(MKDIR_P), but GNU Emacs could override this

Re: problems in Emacs with GL_GENERATE_STDINT_H

On 12/19/21 02:35, Bruno Haible wrote: It would be possible to replace, in the module descriptions: $(MKDIR_P) '%reldir%' && \ with { test '%reldir%' = '.' || $(MKDIR_P) '%reldir%'; } && \ It's a micro-optimization. A trade-off between execution speed and readability. It's

Re: problems in Emacs with GL_GENERATE_STDINT_H

On 12/18/21 05:55, Bruno Haible wrote: Change emacs/configure.ac to use this: AC_DEFUN([AM_CONDITIONAL], [$2 && $1_CONDITION=1 || $1_CONDITION= AC_SUBST([$1_CONDITION])]) and at the same time, change gnulib-tool through the attached patch. Thanks much for the diagnosis and

[PATCH] nstrftime: simplify by using libc-config.h.

++--- modules/nstrftime | 1 + 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/ChangeLog b/ChangeLog index 0dcd3c0dca..61f68406b4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2021-12-18 Paul Eggert + + nstrftime: simplify by using libc-config.h

Re: Accommodate non-recursive Automake in a less hacky way

a3..6fee602cc 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2021-12-16 Paul Eggert + getopt-posix: omit unnessary building of getopt.h + * modules/getopt-posix (getopt.h, getopt-cdefs.h): + Build only if GL_GENERATE_GETOPT_H. + stdint: omit duplicate gl_CONFIGURE_HEADER call

problems in Emacs with GL_GENERATE_STDINT>H

ADER([fnmatch.h])" duplicating fnmatch-h, modules/glob's "gl_CONDITIONAL_HEADER([glob.h])" duplicating glob-h, and modules/iconv_open's "gl_CONDITIONAL_HEADER([iconv.h])". However, I left those alone for now because Emacs doesn't use them. From 88f5ae75df708299b72129da825

Re: Accommodate non-recursive Automake in a less hacky way

On 12/16/21 03:42, Bruno Haible wrote: Jim Meyering wrote: I want to switch every package for which I used the hacky way. This patch is all you need for coreutils. Thanks, I installed that.

[PATCH] bootstrap: refactor for GNU tar

++-- 2 files changed, 118 insertions(+), 110 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6a641703b..d370165cb 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2021-12-12 Paul Eggert + + bootstrap: refactor for GNU tar + * build-aux

Re: [PATCH v2] canonicalize-lgpl: Canonicalize casing too for MinGW.

On 12/11/21 03:35, Jan Nieuwenhuizen wrote: It looks like the inode returned by stat is always 0 on MinGW (at least it is under wine), so also when choosing this approach we would need to special case our client code for MinGW? Yes, you'll have problems on such platforms. For ideas about this,

Re: [PATCH v2] canonicalize-lgpl: Canonicalize casing too for MinGW.

On 12/9/21 22:59, Jan Nieuwenhuizen wrote: We are using the canonical form as an automatic include guard, to not include the same file twice. Gnulib's same-inode module is often a better way to attack that problem.

Re: bug#52410: "mv -T --backup=numbered hello world/" renameat2 infinite loop

ls and add a regression test.From d1b9e7c84959fb0f7014f03fc8746caa125f3d55 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 10 Dec 2021 13:31:02 -0800 Subject: [PATCH 1/3] backupfile: fix numbered backups for XXX/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Enco

Re: [PATCH] canonicalize-lgpl: Canonicalize drive and dirsep too for MinGW.

On 12/10/21 04:06, Jan Nieuwenhuizen wrote: (thanks to your input on my previous patch, we discussed and decided not to do case folding in our client code either). That patch still tries to case-fold one-letter drive specs, though - why bother doing that if you don't case-fold the rest of the

Re: gnulib fails for build on Mac OS X 10.4: get_ppid_of.c:36:22: error: libproc.h: No such file or directory

On 12/9/21 04:28, Ryan Schmidt wrote: (They used __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ instead of MAC_OS_X_VERSION_MIN_REQUIRED; the distinction is not clear to me. It might be that __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is defined even if AvailabilityMacros.h is not included.)

Re: [PATCH v2 08/10] Fix up a bunch of "gcc -Werror=sign-compare" complaints

On 12/8/21 07:48, Bruno Haible wrote: 2) When I collect all warnings in the gllib/ directory of a full testdir, I get (with gcc-9.3): Typically, I don't worry much about warnings by older GCCs, as it's enough of a pain to worry about the latest version. Like Jim I don't have strong

Re: [PATCH v2 08/10] Fix up a bunch of "gcc -Werror=sign-compare" complaints

On 12/7/21 11:44, Robbie Harwood wrote: it's odd to me to hear disabling it being the suggested course of action (especially given it's in the gcc -Wextra set, not some random flag). Not odd at all. High-quality static-checking tools have tons of options for a reason, and one shouldn't assume

Re: [PATCH v2 05/10] Make gnulib's regcomp not abort()

On 12/7/21 10:51, Robbie Harwood wrote: I don't believe we have an implementation of abort() that can be called. (We have grub_abort() instead.) If that's the correct reason, then DEBUG_ASSERT would work and I can make that change. Looking into the code a bit more, it looks like a

Re: [PATCH v2 02/10] gnulib/regexec: Fix possible null-dereference

ent place, since we shouldn't need to worry about the assertion unless top < next_state_log_idx.From 12df33fed758c4cb71b8ae38b973657ca941faec Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 7 Dec 2021 14:34:21 -0800 Subject: [PATCH] regex: pacify Coverity clean_state_log_if_needed P

Re: [PATCH] Fixed tests build on EDG-based compilers

Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 6 Dec 2021 10:29:54 -0800 Subject: [PATCH] intprops: streamline and get ready for Clang 14 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lib/intprops.h (_GL_HAS_BUILTIN_ADD_OVERFLOW): Rely on __has_

Re: [PATCH] Fixed tests build on EDG-based compilers

On 12/5/21 15:41, Bruno Haible wrote: - Why does a compiler define __GNUC__ or __clang__ when it does not behave like GCC or clang? - Why are people at altlinux.org attempting to support a proprietary compiler? Both good questions, especially since this issue (whatever it is:

Re: [PATCH v2 05/10] Make gnulib's regcomp not abort()

On 12/1/21 19:20, Paul Eggert wrote: On 12/1/21 13:02, Robbie Harwood wrote: @@ -1099,7 +1099,7 @@ optimize_utf8 (re_dfa_t *dfa)   }   break;     default: -    abort (); +    break;     } Likewise, it's not clear why this change is needed. The 'abort' should not be reachable

Re: [PATCH v2 00/10] Code hygiene fixes from grub

On 12/1/21 18:00, Bruno Haible wrote: I will go through your patches this Friday, except for the regex ones, that I'll leave to Paul. Thanks for the re-submission and the patience. Yes, thanks for going to all that work. Some of the other patches look good but I'll let Bruno take a look.

Re: [PATCH v2 08/10] Fix up a bunch of "gcc -Werror=sign-compare" complaints

On 12/1/21 13:02, Robbie Harwood wrote: diff --git a/lib/argp-fmtstream.c b/lib/argp-fmtstream.c index f679751b9..4aa401e2d 100644 --- a/lib/argp-fmtstream.c +++ b/lib/argp-fmtstream.c @@ -234,7 +234,7 @@ __argp_fmtstream_update (argp_fmtstream_t fs) else { size_t

Re: [PATCH v2 05/10] Make gnulib's regcomp not abort()

On 12/1/21 13:02, Robbie Harwood wrote: @@ -1099,7 +1099,7 @@ optimize_utf8 (re_dfa_t *dfa) } break; default: - abort (); + break; } Likewise, it's not clear why this change is needed. The 'abort' should not be reachable. Is the intent to make the

Re: [PATCH v2 05/10] Make gnulib's regcomp not abort()

It's not clear why this change is needed. POSIX says that for regerror "the application shall ensure is the last non-zero value returned by regcomp() or regexec() with the given value of preg". If an application violates a "shall" requirement, behavior is undefined so it's OK for regerror to

Re: [PATCH v2 03/10] gnulib/regexec: Resolve unused variable

On 12/1/21 13:01, Robbie Harwood wrote: The reason for this issue is that we are not building with DEBUG set and this in turn means that the assert() that reads the value of the variable match_last is being processed out. Could you explain what goes wrong? regexec_internal.h does this: #if

Re: [PATCH v2 02/10] gnulib/regexec: Fix possible null-dereference

On 12/1/21 13:01, Robbie Harwood wrote: It appears to be possible that the mctx->state_log field may be NULL, I don't see how. re_search_internal sets mctx.state_log to a non-null value if dfa->has_mb_node, and clean_state_log_if_needed should be called only if dfa->has_mb_node is true. What

Re: [PATCH] lib/getrandom.c: fix build with uclibc < 1.0.35

Thanks for checking; I installed the attached.From 217f0da0ed9bc24792791ad83133c6547acfc899 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 30 Nov 2021 17:50:01 -0800 Subject: [PATCH] sys_random: port better to uClibc < 1.0.35 Problem reported by Fabrice Fontaine in: https://lists.gnu.

Re: [PATCH] lib/getrandom.c: fix build with uclibc < 1.0.35

On 11/30/21 13:36, Fabrice Fontaine wrote: Should I send a new patch ? Would something like the following work? diff --git a/lib/sys_random.in.h b/lib/sys_random.in.h index 1abd6c544e..fdc84e0806 100644 --- a/lib/sys_random.in.h +++ b/lib/sys_random.in.h @@ -23,8 +23,10 @@ #if

Re: [PATCH] lib/getrandom.c: fix build with uclibc < 1.0.35

On 11/30/21 09:29, Fabrice Fontaine wrote: +#include #include This surely isn't the right fix, as is supposed to include on uClibc. See gnulib/lib/sys_random.in.h's comment about uClibc. Could you investigate why that part of sys/random.h isn't working on your platform?

Re: compiling with tcc fails on regex.c since commit 56b32251

f00090baf8f31644d9da9a99548548fab8b710ec Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 27 Nov 2021 00:00:46 -0800 Subject: [PATCH 1/3] regex: port to tcc Problem reported by Benno Schulenberg in: https://lists.gnu.org/r/bug-gnulib/2021-11/msg00038.html * modules/regex (Depends-on): Depend on vararrays, since lib/regex.h uses

Re: tests: dis/allow '.' in PATH?

On 11/24/21 15:03, Bernhard Voelker wrote: Sure, the attached is an approach with shell tools Can't this be done without using any subsidiary commands? Something like the following untested code. This removes all relative names from PATH, not just '.'. saved_IFS=$IFS IFS=: new_PATH= for

[PATCH 1/2] regex: assume RE_ENABLE_I18N

/regex_internal.h | 44 ++- lib/regexec.c| 73 +++ modules/regex| 1 + 7 files changed, 121 insertions(+), 350 deletions(-) diff --git a/ChangeLog b/ChangeLog index efc3a3887e..85674b1058 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2021-11-23 Paul Eggert

[PATCH 2/2] regex: merge from glibc

/ChangeLog @@ -1,3 +1,30 @@ +2021-11-24 Paul Eggert + + regex: merge from glibc + The main change here, imported from Glibc, is for the regex + code to stop using nested functions when _LIBC is defined. + The intent is for the result to be copied back to Glibc + so

Re: tests: dis/allow '.' in PATH?

On 11/23/21 14:19, Bernhard Voelker wrote: Of course, the findutils tests could (and probably will) remove '.' from PATH, but I wonder if this should or should not be done for other packages via a change in 'tests/init.sh' as well? Sounds good to me. It might also help to sanitize other

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/16/21 08:40, Sudhip Nashi via GNU coreutils Bug Reports wrote: It looks like this patch fixes the problem, and a quick checksum verifies this. Thanks for checking. Closing the Coreutils bug report.

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

agated it into coreutils. Please try the latest coreutils version on Savannah, or you can simply run configure+make from the tarball that is temporarily at: https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001 From: Paul

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

agated it into coreutils. Please try the latest coreutils version on Savannah, or you can simply run configure+make from the tarball that is temporarily at: https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001 From: Paul

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 16:02, Sudhip Nashi wrote: It doesn’t seem like this patch works. I compiled from the tarball you provided, but the destination file is still filled with NULL chars. Too bad. Can you do a dtruss or at least a ktrace/kdump for the failing program? I'd like to see what lseek is

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz Thanks.From 4db8db34112b86ddf8bac48f16b5acff732b5fa9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 15 Nov 2021 15:08:25 -0800 Subject: [PATCH] lseek: port around macOS SEEK_DATA glitch Problem reported by Sudhip Nashi (Bug#51857

Re: [PATCH] m4/stack-direction.m4: fix build on or1k

Thanks, I installed that patch, as well as the patch for microblazeel.

Re: [PATCH 01/11] Fix base64 module to work with grub codebase

On 10/28/21 12:32, Robbie Harwood wrote: I don't know why Patrick chose to not use that instead, but a local test seems to work. Is grub2 intended to be portable to compilers that don't support ? If that's the issue, I suggest that grub2 stop worrying that. Surely every compiler of interest

[PATCH] exclude: yield proper errno on failure

--- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2021-11-09 Paul Eggert + + exclude: yield proper errno on failure + * lib/exclude.c (add_exclude_file): Do not assume that fclose + preserves errno on success. + 2021-11-07 Paul Eggert regex: break regcomp.c link with glibc

Re: regex module compilation error

for this file so I installed the attached as a workaround. From b9b1bd31378af853378f43047beca0c4174a67d5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 7 Nov 2021 23:31:08 -0800 Subject: [PATCH] regex: break regcomp.c link with glibc Problem reported by Bruno Haible in: https

[PATCH] * doc/gnulib-intro.texi: Fix some ancient history.

--- doc/gnulib-intro.texi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.texi index b88139a2b..049c8ab3d 100644 --- a/doc/gnulib-intro.texi +++ b/doc/gnulib-intro.texi @@ -251,10 +251,11 @@ integers use a ones'-complement

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

On 11/1/21 17:46, Jeffrey Walton wrote: I believe that's undefined behavior. Yes, of course it is. But the Gnulib code works on all practical platforms, so it's OK. Gnulib is a practical project not a theoretical one, and it uses undefined behavior in several ways other than this one. As

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

On 10/21/21 12:38, Paweł Krawczyk wrote: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gl_array_list.c:452:29 in The Gnulib portability assumptions

Re: Emacs build fails on Windows mingw64

On 10/24/21 9:58 AM, Eli Zaretskii wrote: We could try all that, but not on the release branch. There, I'd like a simple and safe fix. Is such a thing possible? Andy suggested a simple fix that I quoted here: https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html We could apply that

Re: Emacs build fails on Windows mingw64

On 10/24/21 6:50 AM, Andy Moreton wrote: An alternative workaround in ntlib.c is to add the missing defines before including : #define _GL_ATTRIBUTE_MALLOC #define _GL_ATTRIBUTE_DEALLOC_FREE Although that works around this particular problem, it is vulnerable to future changes in Gnulib that

Re: Emacs build fails on Windows mingw64

rom: Paul Eggert Date: Sat, 23 Oct 2021 20:35:18 -0700 Subject: [PATCH] Include first in MS-Windows source --- lib-src/ntlib.c | 3 +++ nt/addpm.c | 4 nt/cmdproxy.c | 3 +++ nt/ddeclient.c | 3 +++ nt/preprep.c| 3 +++ nt/runemacs.c | 3 +++ 6 files changed, 19 inserti

Re: Emacs build fails on Windows mingw64

. Proposed Emacs patch attached. I haven't tested or installed this, as I don't use MingW. >From 7bb574b48c7c8be0eb1e941c6da048cfb509cdff Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 23 Oct 2021 20:35:18 -0700 Subject: [PATCH] Include first in MS-Windows source --- lib-src/ntlib.c | 2 ++

Re: [PATCH 4/8] xalloc: new function xreallocarray

(+) diff --git a/ChangeLog b/ChangeLog index a017453dc..2f19e30a2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2021-10-19 Paul Eggert + + xalloc: new function xinmalloc + * lib/xmalloc.c (xinmalloc): New function, which is like + xnmalloc but for idx_t instead of size_t. + 2021-10-18

[PATCH] regex: improve comment

--- lib/regexec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/regexec.c b/lib/regexec.c index a955aa218..106f9d7ff 100644 --- a/lib/regexec.c +++ b/lib/regexec.c @@ -758,8 +758,7 @@ re_search_internal (const regex_t *preg, const char *string, Idx length,

Re: heap-buffer overflow when searching for regex @\*

: https://sourceware.org/bugzilla/show_bug.cgi?id=28470 and I'll try to make sure it gets fixed there too.From f14df82a3f36f833ad1174d293c9c2e33f2a2bea Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 18 Oct 2021 14:50:16 -0700 Subject: [PATCH] regex: fix buffer read overrrun * config

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD

On 10/16/21 2:06 PM, Jeffrey Walton wrote: Related, that may affect Solaris, too. I believe Sun prefers the amd64 prefix. We should be OK there. I just did a "pkg install editor/gnu-emacs" on Solaris 11.4, and its (emacs-version) returns "GNU Emacs 25.2.1 (x86_64-pc-solaris2.11, X toolkit,

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD

On 10/16/21 9:40 AM, Tijl Coosemans wrote: Where necessary we simply pass --build=x64_64-portbld-freebsd$(version). An example is gcc. Could you pass --build=x64_64-portbld-freebsd$(version) to every 'configure' invocation, not just gcc's and a few others? If I understand you correctly,

Re: emacs: macOS warning in lib/nproc.c

the attached. >From 720d73c395bb2fcbae3566339a4102b485aa491d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 15 Oct 2021 19:33:46 -0700 Subject: [PATCH] nproc: port better to macOS 10.14 * lib/nproc.c (num_processors_ignoring_omp) [HAVE_SYSCTL && !defined __GLIBC__ && defined H

Re: close() behavior when there are multiple fds for a socket

On 10/14/21 16:53, Ben Pfaff wrote: The chair of the group appears to be Andrew Josey, but he hides his email Sorry, I should have told you it's Andrew Josey .

Re: close() behavior when there are multiple fds for a socket

On 10/14/21 16:03, Ben Pfaff wrote: https://pubs.opengroup.org/onlinepubs/9699919799/ This specification has a lot of cases that explicitly apply only to the last close of an object, either using that language or by saying that something happens when "all file descriptors associated with" an

Re: double _close()?

On 10/14/21 3:47 AM, Gisle Vanem wrote: Maybe a memory-mapped I/O in GNU-diff could improve the speed? I tried this lng ago (circa 1990) with either GNU grep or GNU diff (can't remember which) and it made performance worse. Of course it's platform-dependent.

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD

On 10/14/21 7:02 AM, Alexey Dokuchaev wrote: All we do is use our pre-built templates for config.{guess,site,sub} and pass the --build=amd64-portbld-freebsd$(version) argument to configure scripts if they are generated by GNU autotools. Surely this doesn't work if there's a configure.ac or

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD

esult in STACK_DIRECTION being 0, which gnulib/lib/stackvma.h does not support (perhaps it should?). From ff5ef2582300c2d982820ffeaede2ea08aaba3d8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 13 Oct 2021 10:24:40 -0700 Subject: [PATCH] sigsegv: fix quoting problem Problem reported for Fre

Re: [PATCH] support for accessing CPU/core count (processor-count)

that emacs/src/w32proc.c's w32-get-nproc function can be removed, I'll let the Emacs MS-Windows experts opine on that. From 7fc3219bcc2bf448ef26cf30a2e5770fdda3f2b4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Oct 2021 10:43:47 -0700 Subject: [PATCH] nproc: port better to OpenBSD

<    5   6   7   8   9   10   11   12   13   14   >