truncate: Work around trailing slash bug in truncate() on AIX

On AIX 7.2, I see this test failure: FAIL: test-truncate === ../../gltests/test-truncate.c:95: assertion 'truncate (BASE "file/", 0) == -1' failed FAIL test-truncate (exit status: 134) Yet another function which need a trailing slash workaround. This patch fixes it. Here, the

ffsll: Override completely broken implementation on AIX in 32-bit mode

On AIX 7.2 in 32-bit mode, ffsll() is completely broken. In some cases it returns the sign bit of the argument, in other cases always 1. This patch provides an override. 2021-01-05 Bruno Haible ffsll: Override completely broken implementation on AIX in 32-bit mode. * m4/ffsll

symlinkat: Fix trailing slash handling

In the symlink() replacement, the trailing slash handling uses lstat() to test whether the designated file exists: struct stat st; if (lstat (name, &st) == 0 || errno == EOVERFLOW) errno = EEXIST; return -1; By symmetry, in the symlinkat() handling, it should use lstatat

link: Improve trailing slash handling on native Windows

On native Windows (but not on Linux!), when stat() fails with error EOVERFLOW, you know that the file is a regular file of size >= 4 GiB. This allows to improve the errno value here: 2021-01-04 Bruno Haible link: Improve trailing slash handling on native Windows. * lib/link.c

mkfifoat: Work around trailing slash bugs on AIX

On AIX 7.2, I'm seeing a test failure: FAIL: test-mkfifoat === ../../gltests/test-mkfifo.h:55: assertion 'func (BASE "fifo/", 0600) == -1' failed FAIL test-mkfifoat (exit status: 134) These two patches fix it. 2021-01-04 Bruno Haible mkfifoat: Work around trailing

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

Paul Eggert wrote: > >> I want the files to be identical (eventually), which is why they have > >> the same include guard. > > Having the same include guard was merely a (wrong) means to the goal. > The goal is for the files to be identical. They can be identical while > using different include

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

> 2021-01-04 Bruno Haible > > libc-config: Avoid overriding the headers from an installed newer glibc. > Reported by Paul E Murphy in > . > * lib/cdefs.h: Use a different include guard than glibc's .

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

On 1/4/21 6:29 PM, Bruno Haible wrote: I want the files to be identical (eventually), which is why they have the same include guard. If they have the same include guard, then Having the same include guard was merely a (wrong) means to the goal. The goal is for the files to be identical. They

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

Hi Paul, > > I see the problem now: glibc's and Gnulib's have > > the same include guard! > > I want the files to be identical (eventually), which is why they have > the same include guard. If they have the same include guard, then 1. People who use a not-yet-released glibc, if they don't w

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

On 1/4/21 5:06 PM, Bruno Haible wrote: I see the problem now: glibc's and Gnulib's have the same include guard! I want the files to be identical (eventually), which is why they have the same include guard. Is there some way to arrange for them to be identical? It could be that this patch

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

Paul E Murphy wrote: > >> The missing macro is provided by glibc's cdefs.h. Thus, the wrong > >> cdefs.h was picked up. > > > > The one from glibc is meant to be included when someone writes > >#include > > > > The one from Gnulib is meant to be included when someone writes > >#include

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

On 1/4/21 12:27 PM, Bruno Haible wrote: Paul E Murphy wrote: We ran into the following: In file included from /home/tuliom/opt/at-next-15.0-0-alpha/include/stdio.h:871, from ./stdio.h:43, from /home/tuliom/tmp/at-build-tray/at15.0-0-alpha.redhat-8_ppc64l

Re: syntax-checks with names containing the letter w not invoked

On Mon, Jan 4, 2021 at 2:22 PM Simon Josefsson via Gnulib discussion list wrote: > Hi. I noticed that 'make syntax-check' never ran syntax checks whose > name contained 'w' on my local machine, but did so on CICD builds. I > tracked it down due to this: > > jas@latte:~/src/gsasl$ echo $LANG > sv

syntax-checks with names containing the letter w not invoked

Hi. I noticed that 'make syntax-check' never ran syntax checks whose name contained 'w' on my local machine, but did so on CICD builds. I tracked it down due to this: jas@latte:~/src/gsasl$ echo $LANG sv_SE.UTF-8 jas@latte:~/src/gsasl$ echo foowbar: | sed -n 's/^\([a-z]*\):/\1/p' jas@latte:~/src

Re: nstftime uses deprecated HAVE_TM_ZONE

Mike Gran wrote: > nstrftime.c uses HAVE_TM_ZONE, but, I think the preferred > define is supposed to be HAVE_STRUCT_TM_TM_ZONE. Indeed, the Autoconf documentation deprecates HAVE_TM_ZONE already since version 2.52. And in other parts of Gnulib, we switched to HAVE_STRUCT_TM_TM_ZONE already 18 year

Re: [PATCH 1/2] posix: User scratch_buffer on fnmatch

* Adhemerval Zanella via Libc-alpha: > It removes the alloca usage on the string convertion to wide characters > before calling the internal function. We have a downstream-only patch to fall back the single byte handling in case of multibyte decoding failure. Basically it's a quick hack to fix t

[PATCH 2/2] posix: Remove alloca usage for internal fnmatch implementation

This patch replaces the internal fnmatch pattern list generation to use a dynamic array. Checked on x86_64-linux-gnu. --- posix/fnmatch.c | 24 +- posix/fnmatch_loop.c | 190 +++ 2 files changed, 87 insertions(+), 127 deletions(-) diff --git a/po

[PATCH 1/2] posix: User scratch_buffer on fnmatch

It removes the alloca usage on the string convertion to wide characters before calling the internal function. Checked on x86_64-linux-gnu. --- posix/fnmatch.c | 152 +--- 1 file changed, 53 insertions(+), 99 deletions(-) diff --git a/posix/fnmatch.c b/

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

Paul E Murphy wrote: > We ran into the following: > > In file included from > /home/tuliom/opt/at-next-15.0-0-alpha/include/stdio.h:871, > from ./stdio.h:43, > from > /home/tuliom/tmp/at-build-tray/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources > /gdb/gnulib/

[PATCH 1/2] posix: Sync tempname with gnulib [BZ #26648]

It syncs with gnulib commit ae9fb3d66 with the following change: --- glibc +++ gnulib @@ -61,7 +61,7 @@ # define __gen_tempname gen_tempname # define __mkdir mkdir # define __open open -# define __lstat64(version, file, buf) lstat (file, buf) +# define __lxstat64(version, file, buf) lstat (file

[PATCH 2/2] posix: Improve randomness on try_tempname_len

For __GT_NOCREATE (mktemp, tempnam, tmpnam) getrandom is also used on first try, otherwise randomness is obtained using the clock plus a linear congruential generator. Also for getrandom GRND_NONBLOCK is used to avoid blocking indefinitely on some older kernels. Checked on x86_64-linux-gnu. ---

Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

On 1/1/21 1:49 PM, Bruno Haible wrote: Hi, Paul Murphy wrote in : While trying to build gdb with ldbl == ieee128 on ppc64le, we found out gnulib's copy of cdefs.h needs to be synchronized with upstream glibc. The only nota

Re: Projects suffer from syntax error

Hi, > I more or less often recompile sources for certain GNU projects, and > at least three projects fail to bootstrap with the same message (only > line numbers vary). They all pull subrepos from gnulib. The problem > seems to be that the autotools generate invald configure scripts. > > texinfo:

Re: Request to revert the C version change

I wanted to test this beforehand but Christmas got in the way. I'm testing the contents of the 2.70 branch now and it's looking good, so thanks very much! Ross On Wed, 23 Dec 2020 at 19:21, Zack Weinberg wrote: > > On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote: > > I'm not happy about n

Projects suffer from syntax error

Hello list, I more or less often recompile sources for certain GNU projects, and at least three projects fail to bootstrap with the same message (only line numbers vary). They all pull subrepos from gnulib. The problem seems to be that the autotools generate invald configure scripts. texinfo: lin

Re: [PATCH v3 4/6] stdlib: Sync canonicalize with gnulib [BZ #10635] [BZ #26592] [BZ #26341] [BZ #24970]

On 01/01/2021 21:04, Paul Eggert wrote: > On 12/30/20 5:10 AM, Adhemerval Zanella wrote: > >>> it is just really >>> a small optimization that adds code complexity on a somewhat convoluted >>> code. > > The code is indeed simpler without the NARROW_ADDRESSES optimization, so I > removed that