Re: getusershell: Split file by lines instead of spaces.

Hi Bruno, You said: >> #if ! defined ADDITIONAL_DEFAULT_SHELLS && defined __MSDOS__ >> # define ADDITIONAL_DEFAULT_SHELLS \ >> "c:/dos/command.com", "c:/windows/command.com", "c:/command.com", > > Inside '#if defined __MSDOS__' or '#if defined _WIN32' this is OK. > I was worried there was explic

Re: Make check - test-vasprintf-posix failure - darwin12 - macos

Gaëtan HERFRAY wrote and Eric Blake forwarded in : > > Actually, make check is failing on test-vasprintf-posix. > > Thanks for the report. This test is maintained by gnulib, so other > projects may see the same failure in that

Re: byteswap side-effect defect report from Coverity

On Mon, May 20, 2024 at 5:43 PM Bruno Haible wrote: > Jeffrey Walton wrote: > > I think this is a valid finding. It will operate one way in release > builds > > (-DNDEBUG), and another way in debug builds (no NDEBUG). > > No. Like Coverity, you are assuming that 'ASSERT' works like 'assert'. > Bu

[PATCH] getopt-posix: port better to Alpine 3.20.0_rc1

Alpine’s is a stub that issues a deprecation #warning. * m4/getopt.m4 (gl_GETOPT_SUBSTITUTE_HEADER): * m4/sched_h.m4 (gl_SCHED_H): Use the new macro gl_CHECK_HEADER_SYS_CDEFS_H instead of checking independently. * m4/sys_cdefs_h.m4: New file. * modules/getopt-posix, modules/sched (Files): Add m4/s

Re: NetBSD utimens, utimensat, etc. failures

Hi Collin, > Done in the two attached patches. Thanks a lot! > It looks like you added the UTIME_OMIT ctime bug to the documentation > in this commit: > > commit e6c7f8be2fe11e72c3fff2503be9ab3f798b787a > Author: Bruno Haible > Date: Sat Jul 25 23:27:40 2020 +0200 > > doc: Updat

Re: byteswap side-effect defect report from Coverity

Jeffrey Walton wrote: > I think this is a valid finding. It will operate one way in release builds > (-DNDEBUG), and another way in debug builds (no NDEBUG). No. Like Coverity, you are assuming that 'ASSERT' works like 'assert'. But it does not. The raison d'être of ASSERT is to work independently

Re: NetBSD utimens, utimensat, etc. failures

Hi Bruno, On 5/20/24 3:54 AM, Bruno Haible wrote: >> I'll leave it for review. > > Looks good to me. Just please change the #if conditions to not test the > *values* of __linux__, __sun, __NetBSD__. That is, the proper way to test > for Linux, Solaris, NetBSD is > defined __linux__ > defined

Re: byteswap side-effect defect report from Coverity

On 5/20/24 14:29, Jeffrey Walton wrote: I think this is a valid finding. It will operate one way in release builds (-DNDEBUG), and another way in debug builds (no NDEBUG). When NDEBUG is in effect, the code `bswap_16 (value_1++) == 0` will be removed. How so? The test program uses 'ASSERT' not

Re: byteswap side-effect defect report from Coverity

On Mon, May 20, 2024 at 12:13 PM Paul Eggert wrote: > Bruno and I get defect reports from Coverity Scan for Gnulib. The most > recent one has this new complaint: > > > *** CID 1588680: Incorrect expression (ASSERT_SIDE_EFFECT) > > /gltests/test-byteswap.c: 43 in test_bswap_eval_once() > > 37 >

Re: byteswap side-effect defect report from Coverity

Hi Bruno, On 5/20/24 12:40 PM, Bruno Haible wrote: >> Interesting. I just learned what a Coverity scan is. Do I have to have >> permission to view the defects? > > I think one needs permission to view and classify these defects, yes. > But it's more boring than anything else, since more than 90%

Re: byteswap side-effect defect report from Coverity

Hi Collin, > Interesting. I just learned what a Coverity scan is. Do I have to have > permission to view the defects? I think one needs permission to view and classify these defects, yes. But it's more boring than anything else, since more than 90% are false alarms. So, if you don't mind, it's su

Re: byteswap side-effect defect report from Coverity

On 5/20/24 12:15, Collin Funk wrote: I just learned what a Coverity scan is. Do I have to have permission to view the defects? I think anybody can sign up, here: https://scan.coverity.com/projects/gnu-gnulib

Re: byteswap side-effect defect report from Coverity

Hi Paul, On 5/20/24 9:13 AM, Paul Eggert wrote: > Gnulib does not support glibc 2.1.x and older, so this should not be a > problem when porting to glibc. However, I worried that other platforms might > have the bug, until I noticed that m4/byteswap.m4 already inadvertently tests > for it. I ins

[PATCH] byteswap: fix problem on macOS

* m4/byteswap.m4 (gl_BYTESWAP): Quote a variable that might not be defined (or the user may have defined it to something with spaces!). Problem reported by Mattias Engdegård for Emacs on macOS. --- ChangeLog | 5 + m4/byteswap.m4 | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-)

[PATCH 1/2] dfa: attempt to pacify Coverity

* lib/dfa.c (lex): Use ‘assume’ rather than ‘abort’, to try to pacify Coverity. (maybe_disable_superset_dfa): Use ‘assume’ here too, for consistency. Using ‘assume’ should make the code a tiny bit faster, though at the cost of having undefined behavior instead of nicely aborting. --- ChangeLog | 9

[PATCH 2/2] linkat-tests: fix up assertion-failure changes

* tests/test-linkat.c (main): Don’t lose the failure results of earlier tests. Problem found by Coverity. --- ChangeLog | 4 tests/test-linkat.c | 15 +-- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 997f51f3b5..ea799492a1

byteswap side-effect defect report from Coverity

Bruno and I get defect reports from Coverity Scan for Gnulib. The most recent one has this new complaint: *** CID 1588680: Incorrect expression (ASSERT_SIDE_EFFECT) /gltests/test-byteswap.c: 43 in test_bswap_eval_once() 37 38 /* Test that the bswap functions evaluate their arguments

Make it easy to generate debug info for libbacktrace on macOS

libbacktrace is meant to work on all platforms, including macOS and mingw. But on macOS, it does not work out of the box: Instead of meaningful stack traces, I only got ../../gltests/test-c32isalnum.c:42: assertion 'ret == n' failed Stack trace: libbacktrace: no debug info in Mach-O executable Se

Re: [PATCH] sha512-buffer: port back to 32-bit-only hosts

Paul Eggert wrote: > > uintN_t arithmetic is overflow-free, just like 'unsigned int' arithmetic. > > Not exactly. For example, this: > >uint16_t a = 46341, b = a * a; > > has undefined behavior on typical platforms with 32-bit int, because > 46341*46341 exceeds 2**31 - 1. Although many prog

Re: [PATCH] getusershell: Work around musl bugs.

Hi Collin, > >> It looks like the current code wants drive-prefixes accepted, i.e. > >> 'c:/ugly/windows/stuff'. > > > > ?? I don't see such code in gnulib/lib/getusershell.c. > > It is defined in the 'ADDITIONAL_DEFAULT_SHELLS' macro [1]: > > > #if ! defined ADDITIONAL_DEFAULT_SHELLS && defin

Re: [PATCH] getusershell: Work around musl bugs.

Hi Bruno, On 5/20/24 3:28 AM, Bruno Haible wrote: >> It looks like the current code wants drive-prefixes accepted, i.e. >> 'c:/ugly/windows/stuff'. > > ?? I don't see such code in gnulib/lib/getusershell.c. It is defined in the 'ADDITIONAL_DEFAULT_SHELLS' macro [1]: #if ! defined ADDITIONAL_DE

Re: NetBSD utimens, utimensat, etc. failures

Hi Collin, > This patch fixes all the failures in my NetBSD virtual machine. > > Essentially, NetBSD 10.0 has the same issues as Linux 2.6 hppa had for > this code. Great! I'm glad that you could do it by just combining existing workarounds. > I'll leave it for review. Looks good to me. Just p

Re: getusershell: Split file by lines instead of spaces.

Hi Collin, > I've attached a patch following this method. I see a method 'next_shell' that is only called in a single place. Would it make sense to inline it (and move its function comments into the body of the caller function)? The main change is to call getline() instead of parsing the file ch

Re: [PATCH] getusershell: Work around musl bugs.

Collin Funk wrote: > It looks like the current code wants drive-prefixes accepted, i.e. > 'c:/ugly/windows/stuff'. ?? I don't see such code in gnulib/lib/getusershell.c. > That sort of breaks the behavior of glibc and BSD where: > > input -> getusershell () output > 'bin/bash' -> '/bas

Re: NetBSD dup3

Hi Collin, > The bug report got addressed today. Nice! That was quick (probably because it was a kernel issue — on libc issues they are much slower). > I think we may have the ordering wrong > in lib/dup3.c: > > if (newfd < 0 || newfd >= getdtablesize () || fcntl (oldfd, F_GETFD) == -1) >