Re: bug#31439: [PATCH] fts: avoid a memory leak edge case

On Monday, May 14, 2018 3:51:02 AM CEST Pádraig Brady wrote: > @@ -122,9 +139,10 @@ main (void) > perror_exit (base, 6); >while ((e = fts_read (ftsp))) > needles_seen += strcmp (e->fts_name, "needle") == 0; > - fflush (stdout); >if (errno) > perror_exit ("fts_read", 7); > +

Re: [PROPOSED] renameatu: rename from renameat2

On Wednesday, July 4, 2018 4:45:32 AM CEST Paul Eggert wrote: > It's looking like Glibc will add a renameat2 function > that is incompatible with Gnulib renameat2; see: > https://sourceware.org/ml/libc-alpha/2018-07/msg00064.html > To help avoid future confusion, rename renameat2 to something else.

Re: cmake support

On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote: > Hi, > > Andrew Pennebaker wrote: > > Could we improve how gnulib integrates with downstream projects, to make > > it > > easier to work with different build tools? In particular, would be helpful > > for gnulib to easily work with c

Re: cmake support

) path and this is most likely not going to change because gnulib's developers do not want gnulib to be used this way: https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-Code.html#Library-vs-Reusable-Code Kamil > On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka wrote: &

Re: cmake support

BUILD_COMMAND echo > INSTALL_COMMAND echo > ) > add_dependencies(fewer gnulib) > target_include_directories(fewer PUBLIC > gnulib-prefix/src/gnulib-build/lib) > target_link_libraries(fewer libgnu) > endif() > > On Sun, Jan 6, 2019 at 3:37 AM Kamil Dudka

Re: make signal handlers more reliable

On Tuesday, March 19, 2019 3:46:54 AM CET Paul Eggert wrote: > Is there some reasonable way to cajole GCC into doing this checking? There is a work-in-progress GCC plug-in that checks signal handlers for uses of functions that are not async-signal-safe: https://github.com/dkozovsk/handler_plug ht

Coverity false positives triggered by gnulib's implementation of base64

Coverity Analysis 2019.03 incorrectly marks the input argument of base64_encode(), and conseuqnetly base64_encode_alloc(), as tainted_data_sink because it sees byte-level operations on the input. It triggered the following false positives in the cryptsetup project: Error: TAINTED_SCALAR: lib/luk

Re: Coverity false positives triggered by gnulib's implementation of base64

Hi Bruno, On Wednesday, May 8, 2019 10:15:37 AM CEST Bruno Haible wrote: > Hi Kamil, > > > Coverity Analysis 2019.03 incorrectly marks the input argument > > of base64_encode(), and conseuqnetly base64_encode_alloc(), as > > tainted_data_sink because it sees byte-level operations on the input. >

Re: Why does close_stdout close stdout and stderr?

On Friday, May 10, 2019 12:17:11 AM CEST Paul Eggert wrote: > On 5/8/19 11:39 PM, Florian Weimer wrote: > > atexit handlers run before ELF destructors (and some C++ destructors). > > There can also be multiple such handlers. So it's not true that an > > atexit handler always runs last. > > OK, bu

Re: Coverity false positives triggered by gnulib's implementation of base64

On Thursday, May 9, 2019 9:14:40 PM CEST Paul Eggert wrote: > On 5/7/19 7:22 AM, Kamil Dudka wrote: > > It triggered the following false positives in the cryptsetup project: > > > > Error: TAINTED_SCALAR: > > lib/luks2/luks2_digest_pbkdf2.c:117: tainted_data_arg

Re: Coverity false positives triggered by gnulib's implementation of base64

atedly review these false positives > > and waive them in each single instance of these tools. And even worse > > with > > gnulib because these false positives are usually not matched across > > different project that bundle gnulib, even if you have a single instance >

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 1:34:55 PM CEST Florian Weimer wrote: > * Kamil Dudka: > >> For example, how do you know that the reports are false positives and not > >> true positives? > > > > I think it was obvious from my previous explanation: > > > >

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 12:13:32 AM CEST Bruno Haible wrote: > Hi Paul, > > > Sorry, I'm still not following. Unless the tainted data is used to > > calculate an array index, there's no problem with Heartbleed and the > > Coverity heuristic should not diagnose a problem. > > Yes, IF they were onl

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 4:11:45 PM CEST Bruno Haible wrote: > Kamil Dudka wrote: > > Thanks! This also helps to suppress the false positives on cryptsetup > > with Coverity Static Analysis version 2019.03. > > Good! Since this is the approach that Paul prefers, I'm push

parse-datetime: invalid date range shifted by 30 minutes for Singapore TZ

In 1981, there was a change in TZ for Singapore and Malaysia which went from UTC+7.5 to UTC+8. It happened at 1981-12-31 23:30:00 which became 1982-01-01 00:00:00. As I understand it, the range 1981-12-31 23:30:00 .. 1981-12-31 23:59:59 should be invalid, whereas the range 1982-01-01 00:00:00

Re: coreutils-9.3 released [stable]

On Tuesday, April 18, 2023 5:16:29 PM CEST Pádraig Brady wrote: > This is to announce coreutils-9.3, a stable release. > This is a bug fix release coming about 4 weeks after the 9.2 release. > See the NEWS below for a summary of changes. Thanks! I had to revert the following gnulib commit to be a

[PATCH] fts: fix a crash triggered by recursive bind mount

insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index c4cb47f..33387c5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2015-02-11 Kamil Dudka + + fts: fix a crash triggered by recursive bind mount + Reported by Michael Chapman in: https://bugzilla.redhat.com

[PATCH v2] fts: avoid crash when a cycle is added while traversing

+ lib/fts.c | 13 ++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index c4cb47f..9daa33c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2015-02-11 Kamil Dudka + + fts: avoid crash when a cycle is added while traversing

[PATCH 1/2] fts: introduce the FTS_NOLEAF flag

The flag is needed to implement the -noleaf option of find. * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag. * lib/fts_.h (FTS_NOLEAF): New macro, shifted conflicting constants. --- lib/fts.c | 4 lib/fts_.h | 12 +--- 2 files changed, 13 insertions(+), 3 deletio

[PATCH 2/2] fts: enable leaf optimization for NFS

NFS provides usable dirent.d_type but not necessarily for all entries of large directories. See for details. * lib/fts.c (leaf_optimization_applies): Append NFS on the white list. --- lib/fts.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/fts.

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Wednesday 09 December 2015 10:35:25 Pádraig Brady wrote: > On 09/12/15 06:34, Kamil Dudka wrote: > > The flag is needed to implement the -noleaf option of find. > > * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag. > > * lib/fts_.h (FTS_NOLEAF): New macro

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Thursday 10 December 2015 01:26:38 Pádraig Brady wrote: > I also noticed a lot of fcntl calls on XFS > (basically one per file), which I need to look further into: > $ strace -c find/find /usr/share >/dev/null > % time seconds usecs/call callserrors syscall > -- --

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: > On the other hand we've had no reports of issues with the > existing auto config done by FTS. Because the leaf optimization has been enabled for reiserfs only until now. I suspect that NFS will not be that easy and such file system issues

test-isinf compiled by gcc-5.3.1 fails on ppc64le

Fedora ppc64le toolchain recently changed expansion of the isinf() macro, which causes the !isinf(LDBL_MAX) assertion to fail when using the LDBL_MAX value defined by gnulib. On the other hand, it still works correctly when using the LDBL_MAX value defined by the toolchain. The -D__SUPPORT_SNA

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 21 December 2015 15:01:56 Kamil Dudka wrote: > On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: > > On the other hand we've had no reports of issues with the > > existing auto config done by FTS. > > Because the leaf optimization has been enabled for re

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 18 January 2016 17:33:54 Pádraig Brady wrote: > On 18/01/16 16:25, Pádraig Brady wrote: > > On 18/01/16 16:10, Kamil Dudka wrote: > >> On Monday 21 December 2015 15:01:56 Kamil Dudka wrote: > >>> On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: >

[PATCH] mountlist: recognize autofs-mounted remote file systems, too

ions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index d2cb956..ba1fc39 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2016-02-19 Kamil Dudka + mountlist: recognize autofs-mounted remote file systems, too + Originally reported at: https://bugzilla.redhat.c

Re: read-write locks

On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote: > Torvald Riegel wrote: > > IMO, users of reader-writer locks should treat them as a > > mutual-exclusion mechanism. That is, a mechanism that just ensures that > > two critical sections will not execute concurrently (except if both are >

Re: [PATCH] dfa: port to gcc -fsanitize=undefined

On Monday, January 16, 2017 10:29:34 Eric Blake wrote: > On 01/15/2017 08:09 PM, Paul Eggert wrote: > > * lib/dfa.c (copy): Don’t pass NULL with size 0 to memcpy, > > as this runs afoul of gcc -fsanitize=undefined. > > It's lame that gcc warns on that usage; I'm half-tempted to propose a > POSIX b

Re: [PATCH] dfa: port to gcc -fsanitize=undefined

On Monday, January 16, 2017 11:57:03 Paul Eggert wrote: > Kamil Dudka wrote: > > It can cause a real crash in certain execution environments. > > Which ones? I'm not interested in environments like -fsanitize=undefined, > which is designed to catch violations of the standa

<    1   2