Re: fstrcmp: memory is not reclaimed on exit

2020-02-12 Thread Akim Demaille
Hi all, > Le 22 janv. 2020 à 07:50, Akim Demaille a écrit : > > I agree, I would like to be able to explicitly release the memory. But > I can't see any API to do that in fstrcmp.c. Is this one ok? I feel > stupid to initialize the memory right before releasing, but I didn't > find a means

Re: vcs_to_changelog.py very slow on a particular commit

2020-02-12 Thread Siddhesh Poyarekar
On 13/02/20 05:11, Simon Marchi wrote: > Hi Siddhesh (and others), > > I'd like to propose that we start using this script for the GDB project [1], > so I tried > to run it on the binutils-gdb repository. It works great until it hits > commit: > > 4934a27c8c1d5c8623366f5dbafae8af60b96bc0

vcs_to_changelog.py very slow on a particular commit

2020-02-12 Thread Simon Marchi
Hi Siddhesh (and others), I'd like to propose that we start using this script for the GDB project [1], so I tried to run it on the binutils-gdb repository. It works great until it hits commit: 4934a27c8c1d5c8623366f5dbafae8af60b96bc0 [binutils][arm] arm support for ARMv8.m Custom

Re: Compile error (again) with GNULIB_NAMESPACE and C++ and Mingw

2020-02-12 Thread Christian Biesinger
On Wed, Feb 12, 2020 at 4:12 PM Christian Biesinger wrote: > This was previously fixed but I again see a compile error (with gnulib > at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4) The previous breakage was reported at https://lists.gnu.org/archive/html/bug-gnulib/2019-11/msg00027.html I suspect

Compile error (again) with GNULIB_NAMESPACE and C++ and Mingw

2020-02-12 Thread Christian Biesinger
Hello! This was previously fixed but I again see a compile error (with gnulib at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4) In file included from /usr/share/mingw-w64/include/io.h:10, from gnulib/import/stdio.h:146, from gnulib/import/wchar.h:80,

Re: XFS reports lchmod failure, but changes file system contents

2020-02-12 Thread Paul Eggert
On 2/12/20 12:01 PM, Florian Weimer wrote: I assumed that an O_PATH descriptor was not intending to confer that capability. I originally assumed the other way, as I don't see any security reason why fchmod should not work on O_PATH-opened descriptors. I see that the Linux man page says

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-02-12 Thread Florian Weimer
* Rich Felker: > Note that in any case, musl's lchmod/fchmodat is not affected since it > always refuses to change symlink modes; I did this because I was > worried that chmod on the magic symlink in /proc might pass through > not just to the symlink it refers to, but to the symlink target if one

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-02-12 Thread Rich Felker
On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote: > On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > > * Paul Eggert: > > > > > On 1/22/20 2:05 PM, Rich Felker wrote: > > >> I think we're approaching a consensus that glibc should fix this too, > > >> so then it would

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-02-12 Thread Rich Felker
On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > * Paul Eggert: > > > On 1/22/20 2:05 PM, Rich Felker wrote: > >> I think we're approaching a consensus that glibc should fix this too, > >> so then it would just be gnulib matching the fix. > > > > I installed the attached patch to

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-02-12 Thread Florian Weimer
* Paul Eggert: > On 1/22/20 2:05 PM, Rich Felker wrote: >> I think we're approaching a consensus that glibc should fix this too, >> so then it would just be gnulib matching the fix. > > I installed the attached patch to Gnulib in preparation for the upcoming > glibc fix. The patch causes