Re: syntax-check rule to silence -Winclude-next-absolute-path warning

On Mon, Feb 19, 2024 at 12:45 AM Simon Josefsson wrote: > Bruno Haible writes: > > --- a/top/maint.mk > > +++ b/top/maint.mk > > @@ -503,6 +503,7 @@ sc_prohibit_have_config_h: > > # Nearly all .c files must include . However, we also permit > > this > > # via inclusion of a package-specific

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

On Mon, Feb 19, 2024 at 10:11 AM Collin Funk wrote: > Jim Meyering writes: > > Thank you both. I've just pushed an improvement. > > The new version runs grep only once rather than many times, and seems > > simpler. > > Thanks. This one seems much better. It also retur

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

On Sun, Feb 18, 2024 at 12:33 PM Bruno Haible wrote: > Collin Funk wrote: > > I attached a patch that seems to work alright. I'm not the greatest with > > GNU Make so it isn't very pretty. Feel free to modify it as much as you > > would like. > > > > Here is some sample output from Coreutils.

Re: test-argp and clang's ASAN

On Sun, Dec 3, 2023 at 4:58 AM Bruno Haible wrote: > In a testdir of module 'argp', built with clang 17 and -fsanitize=address, > I see this test failure: > > $ cat test-argp-2.sh.log > --- expected2023-12-03 12:52:58.892318895 +0100 > +++ out 2023-12-03 12:52:58.904318928 +0100 > @@ -27,9

Re: [PATCH] announce-gen: Allow using local git user.name.

On Mon, Jul 17, 2023 at 1:12 PM Simon Josefsson via Gnulib discussion list wrote: > Hi. I think announce-gen should use the username provided by the > per-repo .git/config rather than the global ~/.gitconfig. > > I hit this corner on build farms where I don't want to modify files > outside of

Re: From wchar_t to char32_t

On Sat, Jul 1, 2023 at 7:35 AM Bruno Haible wrote: > > Here is a proposed patch to overcome the wchar_t limitation in the 'dfa' > module. > > Jim: The background is explained in > > The plan was exposed in >

Re: uses of xinmalloc and xpmalloc triggered make syntax-check failure

On Fri, Jun 9, 2023 at 3:39 AM Pádraig Brady wrote: > On 07/06/2023 05:34, Jim Meyering wrote: > > I noticed some syntax-check failures in diffutils. > > Its uses of relatively new xinmalloc and xpmalloc functions triggered a > > "make syntax-check" fail

Re: uses of xinmalloc and xpmalloc triggered make syntax-check failure

On Wed, Jun 7, 2023 at 1:38 AM Bruno Haible wrote: > Jim Meyering wrote: > > regenerate regex to reflect new functions in xalloc.h > > How did you do that? By hand, or using some of the techniques from [1] or [2]? Hi Bruno, the comments just above include the commands

uses of xinmalloc and xpmalloc triggered make syntax-check failure

rrent list of functions. I expect to regenerate other syntax-checked header regexps and may find time to automate the update process. >From 1496e1fbe5bd7a9302d9168e9dc1864f1e435547 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 6 Jun 2023 20:49:22 -0700 Subject: [PATCH] maint.mk: reg

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On Wed, May 31, 2023 at 9:12 AM Pádraig Brady wrote: > On 30/05/2023 22:29, Paul Eggert wrote: > > On 5/28/23 06:07, Pádraig Brady wrote: > >> There still is a gotcha (hit in dd.c in coreutils) > >> where if you define an error macro yourself > >> you get a macro redefinition error, > > > > I see

Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

On Sun, May 28, 2023 at 10:44 AM Bruno Haible wrote: > How about adding -Wno-suggest-attribute to the list of warning options that > are part of the GL_CFLAG_GNULIB_WARNINGS variable, no that such warnings > function might be candidate for attribute 'pure' > or > function might be candidate

Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

On Sun, May 28, 2023 at 10:08 AM Bruno Haible wrote: > > Hi Jim, > > Jim Meyering wrote: > > FYI, just pushed, to avoid this: > > > > lib/file-has-acl.c: In function 'have_xattr': > > lib/file-has-acl.c:54:1: error: function might be candidate for

[PATCH] file-has-acl: avoid warning from bleeding-edge GCC

, ssize_t listsize) >From 2bd4c8dc13de3121d76dad755a255c8e92fd46a7 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 28 May 2023 09:41:08 -0700 Subject: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC * lib/file-has-acl.c: Include attribute.h. (have_xattr): Declare with ATTRIBUTE_P

Re: [bug-diffutils] bug#63333: [PATCH] Add hurd-amd64 support

On Sat, May 6, 2023 at 8:34 PM Samuel Thibault wrote: > This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case > > --- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 + > +++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 + > @@ -351,6 +351,17 @@ > "old esp, if

Re: FYI: disable gnulib's strtoull and strtoll tests

On Wed, May 3, 2023 at 1:34 AM Bruno Haible wrote: > Hi Jim, > ! It smells like you are using an old config.cache ? > > Or possibly there is a 'config.site' file? The configure output should > show if one is loaded. Thanks for looking, Bruno. I think you must be right about it being due to an

Re: FYI: disable gnulib's strtoull and strtoll tests

On Sun, Apr 30, 2023 at 11:14 PM Jim Meyering wrote: > > On Sun, Apr 30, 2023, 22:54 Bruno Haible wrote: >> >> Hi Jim, >> >> > We've seen gnulib's new strtoll and strtoull tests for 0x and 0b failing >> > on too many systems >> >> Can you ple

Re: FYI: disable gnulib's strtoull and strtoll tests

On Sun, Apr 30, 2023, 22:54 Bruno Haible wrote: > Hi Jim, > > > We've seen gnulib's new strtoll and strtoull tests for 0x and 0b failing > > on too many systems > > Can you please name one (or some of) these systems? So that I can > reproduce the problem. And, if you have it readily available, >

FYI: disable gnulib's strtoull and strtoll tests

rom 2ea921979769dc49865931f82f5e1d75b957ee83 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 30 Apr 2023 02:55:16 -0700 Subject: [PATCH] tests: temporarily omit gnulib's strtoll and strtoull tests * bootstrap.conf (avoided_gnulib_modules): Omit strtoll and strtoull tests, because the edge-case 0[bx] tests fail on rec

[PATCH] tests: set executable bit in test-trim[1-3].sh

I tried latest gnulib with grep and saw three easily-fixed failures, so I've pushed this: >From d7e034a02c4ede22045be9165e68cea1990cfd6a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 3 Apr 2023 12:27:46 -0700 Subject: [PATCH] tests: set executable bit in test-trim[1-3].sh This avo

[PATCH] gnu-web-doc-update: don't use host alias, cvs.sv.gnu.org

The usual post-release command to update grep-3.10's web docs failed for me. This fixed it. >From 78f594f7ac9315c655f663976da1d42a4ccb9b21 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 22 Mar 2023 19:51:12 -0700 Subject: [PATCH] gnu-web-doc-update: don't use host alias, cvs.sv.gnu.

Re: bug#62267: grep-3.9 bug: \d matches multibyte digits

On Sun, Mar 19, 2023 at 4:12 PM Paul Eggert wrote: > On 2023-03-19 13:44, Jim Meyering wrote: > > I've pushed your change along with the attached. > > I'll probably create another snapshot today. > > Thanks. I also installed a minor dfa.c change in Gnulib yesterday to &g

Re: removing permissions for long unused accounts, take 2

On Thu, Mar 9, 2023 at 8:49 AM Paul Smith wrote: > > On Thu, 2023-03-09 at 15:54 +0100, Bruno Haible wrote: > > If you have a checkout of GNU gnulib, in order to successfully do a > > "git pull" again, you will have to change the .git/config file, > > Is it better to suggest Git's CLI interface

Re: [PATCH] bootstrap: remove code that accommodated RHEL5's old autoreconf

On Thu, Mar 9, 2023 at 9:14 AM Bruno Haible wrote: > Hi Jim, > > $ /gnu-inst-autoconf/2.59/bin/autoreconf --help | grep no-recursive > $ /gnu-inst-autoconf/2.60/bin/autoreconf --help | grep no-recursive > --no-recursive don't rebuild sub-packages > $

[PATCH] bootstrap: remove code that accommodated RHEL5's old autoreconf

FYI, I've just pushed this: >From 074cf4b3753f2f37927eebdad8ebb1dd74ba057f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 9 Mar 2023 08:41:07 -0800 Subject: [PATCH] bootstrap: remove code that accommodated RHEL5's old autoreconf * top/bootstrap-funclib.sh (autogen) [AUTORECONFFL

Re: License of module "Perl" seems wrong

On Mon, Feb 27, 2023 at 6:05 AM Bruno Haible wrote: > Hi Reuben, > > Reuben Thomas wrote: > > The perl module has a GPL license, but its only file, m4/perl.m4, has an > > "unlimited" license. > > The license of a module, in the module description, cannot be "wrong" since > that's the

Re: FYI: announce-gen: add more info to the auto-generated announce template

On Sat, Feb 25, 2023 at 11:56 PM Bruno Haible wrote: > Jim Meyering wrote: > > from coreutils-9.2 or openBSD's cksum since 2007. > > It's the first time I see OpenBSD spelled this way. Why not use an > uppercase 'O', like they do themselves [1] ? Thanks. Corrected.

FYI: announce-gen: add more info to the auto-generated announce template

ce 3.7. See the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Carlo Marcelo Arenas Belón (2) Helge Kreutzmann (1) Jim Meyering (27) Ondřej Fiala (1) Paul Eggert (71) Ulrich Eckhardt (2) Jim [on

Re: fts: Document this module

On Thu, Jan 19, 2023 at 7:05 PM Paul Eggert wrote: > > On 1/19/23 15:41, Bruno Haible wrote: > > Jim or Paul, what should we state > > — either in the 'fts' module description, or in the .texi documentation? > > The quick thing is to say in both that the description/documentation is > incomplete,

Re: RFC: git-commit based mtime-reproducible tarballs

On Mon, Jan 16, 2023, 12:41 AM Simon Josefsson via Gnulib discussion list < bug-gnulib@gnu.org> wrote: > Bruno Haible writes: > > > Paul Eggert wrote: > >> some users want to "trust but verify" and a reproducible > >> tarball is easier to audit than a non-reproducible one, so for these > >>

Re: FYI: update-copyright: also work with two or more updatable lines

On Tue, Jan 10, 2023 at 8:37 PM Jim Meyering wrote: > FYI, I've just pushed this fix. > I noticed this bug when attempting to update gzip's copyright dates. > It has a few files with two copyright lines. > The old version of this script would update only the first one. For the reco

FYI: update-copyright: also work with two or more updatable lines

,10 @@ +2023-01-10 Jim Meyering + + update-copyright: also work with two or more updatable lines in a file + * build-aux/update-copyright: Replace every occurrence of the copyright + line, not just the first one. + * tests/test-update-copyright.sh: Add a test case for this. + 2023-01-10 Bruno Hai

Re: [PATCH] vc-list-files-tests: Avoid OpenPGP private key operations.

On Sun, Nov 13, 2022 at 3:00 AM Simon Josefsson via Gnulib discussion list wrote: > Hi. I had a background job doing 'make check' in a project that > triggered a GnuPG private key operation PIN prompt... this was > surprising to me, and the attached fix should avoid that happening. If > my PIN

Re: maint.mk: public-submodule-commit rule is broken

On Mon, Sep 12, 2022 at 3:32 AM Simon Josefsson wrote: > Btw, see my concerns with this code earlier here: > > https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00040.html > https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00044.html > > Instead of the patch, I have merely disabled

Re: Fix a couple of ShellCheck warnings

On Sat, Jul 23, 2022 at 1:57 PM Bruno Haible wrote: > The other issues reported by ShellCheck are pretty harmless. Still, fixing > some of them can improve security or code clarity. > > 2022-07-23 Bruno Haible > > Fix a couple of ShellCheck warnings. > * MODULES.html.sh

Re: removing permissions for long unused accounts, take 2

On Tue, Jul 12, 2022 at 10:18 PM Bruno Haible wrote: > Hi, > > I started this topic in 2021, in [1]: a proposal to remove write > permissions from accounts who haven't pushed in a long while. > There was agreement [2] that contributors who had not directly pushed > a commit in a year could be

Re: announce-gen usage feedback

On Sat, Jul 9, 2022 at 6:29 AM Simon Josefsson via Gnulib discussion list wrote: > > Bruno Haible writes: > > > Hi Simon, > > > > Two remarks regarding 'announce-gen': > > > > 1) I used the command > >$ $GNULIB_SRCDIR/build-aux/announce-gen --release-type stable \ > >--package-name

FYI, fix the hash.h inclusion-not-needed syntax-check rule

FYI, I've just pushed this fix for the hash.h syntax-check rule: >From fc555c0a4bf23b3418e0e9cc3a0800172b716b90 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 23 Jun 2022 08:12:44 -0700 Subject: [PATCH] maint.mk: fix syntax-check for unnecessary hash.h header use * top/maint

Re: [PATCH 2/3] dfa: new option DFA_STRAY_BACKSLASH_WARN

On Mon, Jun 6, 2022 at 3:06 PM Paul Eggert wrote: > On 6/6/22 12:37, Jim Meyering wrote: > > Once you push that (and assuming you have nothing else pending), I'll > > prepare another pre-release snapshot. > > Thanks, I pushed it into grep master, after fixing the commentar

Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?

On Sun, Jun 12, 2022, 1:11 PM Paul Eggert wrote: > The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and > the glibc manual pretty much recommends against them. How about if we > drop Gnulib support for them? This would speed up 'configure' a bit, > among other things. As far as

Re: [PATCH 2/3] dfa: new option DFA_STRAY_BACKSLASH_WARN

On Sun, Jun 5, 2022 at 10:45 AM Paul Eggert wrote: > On 6/4/22 18:45, Bruno Haible wrote: > > And maybe some people find it OK to get the "stray \ before -" warning for > >grep -e '\-x' FILE > > and to inhibit it only when the option -e or the marker '--' is not used? > > Yes, thanks, this

Re: "grep '\]'" warnings suggest a Gnulib DFA patch

On Fri, Jun 3, 2022 at 8:09 PM Bruno Haible wrote: > Paul Eggert asked: > > So, what do you think of the idea of not warning for this particular > > stray backslash? Proposed Gnulib patch attached, with the idea of > > propagating this into GNU grep before its upcoming release. I haven't > >

Re: [platform-testers] Test failures for grep-3.7.62-9a668

On Sat, Apr 30, 2022 at 1:14 PM Bruno Haible wrote: > Nelson H. F. Beebe wrote: > > I did builds of grep-3.7.62-9a668 on 29 systems today ... > > > > On Solaris 11.4 x86_64: > > > > ../build-aux/test-driver: line 112: 14630: Memory fault > > ../build-aux/test-driver: line 112: 15129:

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

rtol: remove unnecessary else after return * lib/xstrtol.c (bkm_scale): Drop "else" after return. diff --git a/ChangeLog b/ChangeLog index 2ea372b0e3..ff78fda8f3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2022-01-17 Jim Meyering + + xstrtol: remove unneces

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

On Wed, Jan 5, 2022 at 9:46 AM Bruno Haible wrote: ... > 2022-01-05 Bruno Haible > > gnulib-tool: Avoid known warnings that reflect Gnulib's coding style. > * m4/gnulib-common.m4 (gl_CC_GNULIB_WARNINGS): New macro. > * gnulib-tool (func_emit_lib_Makefile_am): Add the >

Re: Some generated header files are messed up on Alpine

On Sat, Jan 1, 2022 at 12:15 PM Bruno Haible wrote: > Paul, > > I suggest the attached patch. Objections? Looks fine to me. Thanks for the speedy fix.

Re: makefile rules

On Tue, Dec 21, 2021 at 5:21 PM Paul Eggert wrote: > 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

Re: makefile rules

On Tue, Dec 21, 2021 at 12:12 PM Paul Eggert wrote: > 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 ch

Re: makefile rules

On Tue, Dec 21, 2021 at 11:41 AM Paul Eggert wrote: ... > If you run 'make' sometimes as one user and sometimes as another, you > can have problems like that no matter what. We don't put 'rm -f $@' at > the start of every other makefile recipe to work around those problems; > why are these

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

On Wed, Dec 15, 2021 at 11:38 AM Ben Pfaff wrote: > On Wed, Dec 15, 2021 at 11:31 AM Bruno Haible wrote: > > With the attached patches, 'gnulib-tool' gains the functionality to > > generate a "non-recursive" Automake Makefile.am snippet, similar to > > what the 'non-recursive-gnulib-prefix-hack'

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

On Wed, Dec 8, 2021 at 7:48 AM Bruno Haible wrote: > > > especially given it's in the gcc -Wextra set, not some random flag > > Warnings in the '-Wall' category are typically worth eliminating: they > regularly point to real bugs. > > Eliminating '-Wsign-compare' warnings, OTOH, is usually a

Re: [PATCH] maint: Avoid syntax-check failure for empty gnulib submodule.

On Mon, Sep 20, 2021 at 12:49 AM Simon Josefsson via Gnulib discussion list wrote: > Hi, > > Some syntax-check rules have a really poor failure mode (it prints all > source code files to stdout) when the 'gnulib_dir' points to an empty > git submodule checkout, see for example: > >

Re: #include on Android clang causes an error

On Thu, Sep 9, 2021 at 12:27 PM Lucy Phipps wrote: > > -- Forwarded message - > From: Lucy Phipps > Date: Thu, Sep 9, 2021 at 11:25 AM > Subject: Re: #include on Android clang causes an error > To: Paul Eggert > > it works perfectly now! and yeah i was planning on applying this

Re: [PATCH] maintainer-makefile: Add indentation syntax-check rule.

On Fri, Sep 3, 2021 at 10:06 PM Simon Josefsson via Gnulib discussion list wrote: > Hi. I realized the main reason I don't consistenly enforce code > indentation in the projects I work on is that it isn't tested before > releases (or via CICD builds). The syntax-check framework to the > rescue!

Re: buildbot failure in OpenCSW Buildbot on ggrep-solaris10-i386

gt;> Buildslave for this Build: unstable10x > >>> > >>> Build Reason: The SingleBranchScheduler scheduler named > >>> 'schedule-ggrep-solaris10-i386' triggered this build > >>> Build Source Stamp: [branch master] > >>> 6aaef3b8a7f109ab8f39fd46ede01a

Re: buildbot failure in OpenCSW Buildbot on ggrep-solaris10-i386

uildbot URL: https://buildfarm.opencsw.org/buildbot/ > > Buildslave for this Build: unstable10x > > Build Reason: The SingleBranchScheduler scheduler named > 'schedule-ggrep-solaris10-i386' triggered this build > Build Source Stamp: [branch master] 6aaef3b8a7f109ab8f39fd46ede01aebbd9f8205 > Bl

Re: announce-gen and OpenPGP key servers

On Tue, Aug 3, 2021 at 12:25 PM Paul Eggert wrote: > On 8/3/21 12:20 PM, Simon Josefsson via Gnulib discussion list wrote: > > + print "\nThe SHA256 checksum is base64 encoded and not hexadecimal,\n"; > > + print "which is the default for most checksum tools.\n\n"; > > Perhaps this? > >

Re: announce-gen and OpenPGP key servers

On Tue, Aug 3, 2021 at 8:40 AM Simon Josefsson wrote: > Jim Meyering writes: > > > Feel free to make the script generate a full fingerprint and even > > (though it feels a little like giving up) add a checksum or two. > > I think checksums still serve a purpose. >

Re: any pending fixes? preparing for diffutils release

On Sun, Aug 1, 2021 at 10:36 PM Paul Eggert wrote: > One minor problem I just discovered with the now-released diffutils 3.8, > a problem that was caused by my recent Gnulib changes, is that building > diffutils on RHEL 8.4 results in diagnostics like the following: > > In file included from

Re: any pending fixes? preparing for diffutils release

On Sun, Aug 1, 2021 at 3:15 PM Paul Eggert wrote: > I've recently been improving some GCC-based static analysis in Gnulib, Welcome changes. Thanks! > and syncing from Gnulib to diffutils meant that you have a bit of a > work-in-progress there. I plan to make further such changes soon. No

any pending fixes? preparing for diffutils release

I am ready to release diffutils-3.8, but in order to get it to compile warning-free with configure's --enable-gcc-warnings and GCC 11.2.1, I had to push another -fanalyze-pacification patch to regex_internal.c, just minutes ago. Given that this made diffutils pull in gnulib changes since the

Re: fts in gnulib behave different than glibc

On Thu, Jul 29, 2021 at 3:22 AM Simon Josefsson wrote: > > Jim Meyering writes: > > > On Wed, Jul 28, 2021 at 1:08 AM Simon Josefsson via Gnulib discussion > > list wrote: > >> Hi. I replaced GNU InetUtils' old custom fts implementation with the > >>

Re: fts in gnulib behave different than glibc

On Wed, Jul 28, 2021 at 1:08 AM Simon Josefsson via Gnulib discussion list wrote: > Hi. I replaced GNU InetUtils' old custom fts implementation with the > one from gnulib, but self-tests started failing. Looking at the code, > it seems gnulib's fts implementation has diverged compared to glibc,

Re: [PATCH] maintainer-makefile: Fix announcement mail CC's.

On Wed, Jul 28, 2021 at 1:50 AM Simon Josefsson via Gnulib discussion list wrote: > Simon Josefsson via Gnulib discussion list writes: > > > Hi. I noticed some typos causing the Cc line in mail announcements to > > be empy where that (most likely) wasn't the intention. > > It seems some

Re: announce-gen and OpenPGP key servers

On Tue, Jul 27, 2021 at 2:38 AM Simon Josefsson via Gnulib discussion list wrote: > Hi. Our announce-gen contains: > > If that command fails because you don't have the required public key, > then run this command to import it: > gpg --keyserver keys.gnupg.net --recv-keys $gpg_key_id > >

Re: warnings in unit tests

On Mon, Jun 7, 2021 at 7:41 PM Bruno Haible wrote: > Hi Jim, > > > > > > @@ -183,6 +183,9 @@ main () > > > > >*(volatile int *) (page + 0x678) = 42; > > > > >break; > > > > > case 3: > > > > > +#if 6 < __GNUC__ > > > > > +# pragma GCC diagnostic ignored "-Wnull-dereference" >

Re: new module 'sigsegv'

On Mon, Jun 7, 2021 at 3:29 AM Dmitry V. Levin wrote: > Hi, > On Mon, Jun 07, 2021 at 02:49:35AM +0200, Bruno Haible wrote: > [...] [...] > > > @@ -183,6 +183,9 @@ main () > > >*(volatile int *) (page + 0x678) = 42; > > >break; > > > case 3: > > > +#if 6 < __GNUC__ > > > +#

Re: test suite failure caused by check-copyright script

On Sun, May 23, 2021, 8:05 AM Bruno Haible wrote: > Does everyone still agree > - to put into the source files a license header that is consistent > with the module description, and > - to remove the statement from the documentation > "The source files always say "GPL", but the real

Re: error, getprogname: Relicense under LGPLv2+

org/gitweb/?p=gnulib.git;a=commitdiff;h=f29814b96c9737abc8193d57d630697700feebeb > Paul Eggert > for > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=aad5573e2e307ba42eea5b6b76b0b9788a5eaaec > > For lib/getprogname.c we would need the approval of > Pino Toscano > Paul

Re: removing permissions for long unused accounts?

On Sun, Feb 21, 2021 at 10:36 AM Jeffrey Walton wrote: > > On Sun, Feb 21, 2021 at 1:20 PM Bruno Haible wrote: > > > > On another GNU mailing list, someone is writing: > > > > Since I no longer work on I give > > you permission to remove my git server access (the key). If I ever > >

Re: different CFLAGS for gnulib code?

On Fri, Jan 15, 2021 at 12:55 AM Bruno Haible wrote: > Jeffrey Walton wrote: > > Perhaps it would be a good idea to filter-out the options that you > > don't want present for Gnulib. ... > It is an interesting idea. Leaving the question aside how it is implemented > (through an AC_SUBSTed

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

On Mon, Jan 4, 2021 at 2:44 PM Jim Meyering wrote: > > 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

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 >

Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

On Sat, Jan 2, 2021 at 7:22 PM Paul Eggert wrote: > On 1/2/21 5:49 PM, Bruno Haible wrote: > > The vast majority of -Wanalyzer* warnings that we have seen so far were > > false > > alarms [1]. > > I've had such bad luck with those warnings that I have not been much > motivated to file GCC bug

vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

I built latest gcc from git and then attempted to build things with it. I noticed this new warning while trying to build diffutils, but haven't had time to address: Making all in lib make[1]: Entering directory '/home/j/w/co/diffutils/lib' make all-am make[2]: Entering directory

FYI, [PATCH] hash: add casts-to-float to avoid clang-10 warnings

I've just pushed the attached: 0001-hash-add-casts-to-float-to-avoid-clang-10-warnings.patch Description: Binary data

Re: Hidden files in autoconf 2.70 distribution?

On Wed, Dec 9, 2020 at 3:49 PM Paul Eggert wrote: > On 12/9/20 7:46 AM, Bruno Haible wrote: > > It comes from Gnulib's git-version-gen and GNUmakefile. > > > > I'm not defending it. In fact, it annoys me. But I didn't spend the > > time to find another way to record the release version. > >

Re: avoid two GCC11 warnings

On Thu, Nov 26, 2020 at 6:11 AM Bruno Haible wrote: > > Building grep with GCC11, I noticed some new warnings. > > Fixed with the just-pushed attached patches. > > Thanks. It's interesting to see GCC's inference capabilities to grow. > > But the second patch causes a compilation error on MSVC: >

avoid two GCC11 warnings

Building grep with GCC11, I noticed some new warnings. Fixed with the just-pushed attached patches. 0002-setlocale-tests-do-not-trigger-gcc-s-Wanalyzer-possi.patch Description: Binary data 0001-raise-tests-avoid-GCC-11-s-new-exit-from-signal-hand.patch Description: Binary data

Re: [PATCH] timeout: support sub-second timeouts on macOS

On Mon, Nov 9, 2020 at 5:17 AM Pádraig Brady wrote: > On 09/11/2020 01:33, Jim Meyering wrote: > > On Sun, Nov 8, 2020 at 1:26 PM Pádraig Brady wrote: > >> On 08/11/2020 18:52, Jim Meyering wrote: > >>> On Sat, Nov 7, 2020 at 2:08 PM Pádraig Brady wrote: &

Re: hash, xhash: modernize

On Fri, Oct 16, 2020 at 7:32 PM Bruno Haible wrote: > Hi Jim, > > > > I tried to make it clear the last time we discussed this (long ago!) > > > that I prefer to keep certain comments very near the function > > > definition (and implementation). > > Yes, I sort of remembered this. Therefore I

Re: hash, xhash: modernize

On Fri, Oct 16, 2020 at 6:07 PM Jim Meyering wrote: > [I wrote this two or so days ago, but see now somehow I failed to send it] > On Sun, Oct 11, 2020 at 2:58 PM Bruno Haible wrote: > > It has been reported today that looking at the 'hash' module made Marc guess > > incorrect

Re: hash, xhash: modernize

[I wrote this two or so days ago, but see now somehow I failed to send it] On Sun, Oct 11, 2020 at 2:58 PM Bruno Haible wrote: > It has been reported today that looking at the 'hash' module made Marc guess > incorrectly what is desired coding style and terminology in Gnulib. I do not desire to

Re: new snapshot available: grep-3.4-almost.50-2a4c

On Sun, Sep 27, 2020 at 12:29 PM Jeffrey Walton wrote: > On Sun, Sep 27, 2020 at 12:20 AM Jim Meyering wrote: > > ... > > grep snapshot: > > https://meyering.net/grep/grep-ss.tar.xz 1.6 MB > > https://meyering.net/grep/grep-ss.tar.xz.sig > > https://

Re: [platform-testers] new snapshot available: grep-3.4-almost.46-b2228

On Fri, Sep 25, 2020 at 5:12 PM Paul Eggert wrote: > > On 9/25/20 4:37 PM, Jeffrey Walton wrote: > > > With the patch applied... The first set of tests got noisy: > > That's odd. I wouldn't expect test-regex.c changes to affect any other test. > > > $ cat

Re: [platform-testers] new snapshot available: grep-3.4-almost.46-b2228

On Fri, Sep 25, 2020 at 3:07 PM Jeffrey Walton wrote: > > On Thu, Sep 24, 2020 at 11:47 PM Jim Meyering wrote: > > ... > > grep snapshot: > > https://meyering.net/grep/grep-ss.tar.xz 1.6 MB > > https://meyering.net/grep/grep-ss.tar.xz.sig > > https

Re: bug#41558: Regexp Bug

On Tue, Sep 22, 2020 at 5:40 PM Paul Eggert wrote: > On 9/22/20 4:40 PM, Jim Meyering wrote: > > Does anyone know if there's a glibc bug number for it? > > I looked for one and didn't find it, so I created glibc bug 26653 for it. See: > > https://sourceware.org/bugzilla/

Re: bug#41558: Regexp Bug

On Wed, May 27, 2020 at 11:30 PM Norihiro Tanaka wrote: > On Tue, 26 May 2020 21:14:12 -0700 > "anton.paras" wrote: > > > I posted to Stack Exchange, and they recommended that I file a bug. I'd > > rather not copy+paste it all, so here's the link: > > > > > > > >

Re: [PATCH] verify: avoid __builtin_assume

On Sun, Sep 20, 2020 at 7:59 AM Bruno Haible wrote: > On 2020-09-06 I wrote: > > The actual failure is a > > FAIL: test-regex > > during "make check". > > > > Like Emacs, the regex code is quite complicated, so it is possible > > that both the Emacs crash and the regex failure are caused by the

test-verify.c: avoid -Wshadow warnings

; | ^ >From 40518bb8dee997613ebabc05331b6701870bdf01 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 19 Sep 2020 19:24:42 -0700 Subject: [PATCH] test-verify.c: avoid -Wshadow warnings * tests/test-verify.c (gx): Rename global from "x". Adjust use. (enum): Capitalize

Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30

On Thu, Sep 17, 2020 at 6:37 AM Jeffrey Walton wrote: > Hi Everyone, > > grep-3.4-almost.19-ff30 fails self test on Alpine Linux 3.10 with > BusyBox, triplet x86_64-pc-linux-gnu. > > FAIL: test-dfa-match.sh Thank you for reporting that. I'll start with that first issue. That is due to a

Re: [PATCH 1/3] dfa: fix dfa-heap-overrun failure

On Mon, Sep 14, 2020 at 6:29 AM Norihiro Tanaka wrote: > On Mon, 14 Sep 2020 00:28:32 -0700 > Paul Eggert wrote: > > > On 9/14/20 12:13 AM, Norihiro Tanaka wrote: > > > > > when (i >= d->follows[i].elems[j].index), it seems that > > > map[d->follows[i].elems[j].index] has been already set a

Re: bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sun, Sep 13, 2020 at 7:03 PM Paul Eggert wrote: > On 9/11/20 11:41 PM, Jim Meyering wrote: > >> https://bugs.gnu.org/40634#32 > >> > >> I'll try to take a look at the later patch. > > > > Oh! Glad you spotted that. > > I took a look and the basic

Re: bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sat, Sep 12, 2020 at 1:01 AM Paul Eggert wrote: > > And here is the adjusted patch: > > Hold on, that looks like a cleanup of the April 18 patch posted here: > > https://bugs.gnu.org/40634#26 > > But there's a later patch dated April 19, which Norihiro Tanaka said should be > more correct and

Re: bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Fri, Sep 11, 2020 at 2:47 PM Jim Meyering wrote: > On Sun, Apr 19, 2020 at 4:10 AM Norihiro Tanaka wrote: > > On Sun, 19 Apr 2020 07:41:49 +0900 > > Norihiro Tanaka wrote: > > > On Sat, 18 Apr 2020 00:22:26 +0900 > > > Norihiro Tanaka wrote: > > >

Re: bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sun, Apr 19, 2020 at 4:10 AM Norihiro Tanaka wrote: > On Sun, 19 Apr 2020 07:41:49 +0900 > Norihiro Tanaka wrote: > > On Sat, 18 Apr 2020 00:22:26 +0900 > > Norihiro Tanaka wrote: > > > > > > > > On Fri, 17 Apr 2020 10:24:42 +0900 > > > Norihiro Tanaka wrote: > > > > > > > > > > > On Fri,

Re: problems with "make install" directory permissions

On Mon, Jul 27, 2020 at 3:03 PM Paul Eggert wrote: > > On 7/27/20 2:24 PM, Karl Berry wrote: > > https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html > > > > I can understand increasing permissions to allow +rx on installation > > directories, but why force 755, thus disallowing group

Re: use O_CLOEXEC in more places

On Wed, May 27, 2020, 11:44 Bruno Haible wrote: > The gnulib module 'open' supports O_CLOEXEC since 2017-08-14. We can use it > to make multithreaded application that call fork() and exec() more robust. > > Here are proposed patches. > > How about module 'fts'? Should the directory fds that it

Re: relicense module 'group-member'

On Thu, May 21, 2020 at 7:44 AM Eric Blake wrote: > On 5/21/20 9:22 AM, Bruno Haible wrote: > > Hi Jim, Paul, Eric, > > > > You are the contributors of the module 'group-member', which is under > > GPLv3+. > > Can you agree to relicensing it under LGPLv2+? > > > > Rationale: > > > > The

Re: list, set, oset, map, omap: avoid imperative voice in documentation

On Sun, Feb 2, 2020 at 4:17 AM Bruno Haible wrote: > Each time I read the function specifications in gl_list.h, the use of > imperative voice ("Return true if ...") feels wrong. "Returns true if ..." is > the correct grammar. > > Why? Because imperative form is used to instruct someone. In the

Re: Your gnulib patch

On Tue, Jan 7, 2020 at 4:41 PM Cong Wang wrote: > > On Fri, Jan 3, 2020 at 3:31 PM Jim Meyering wrote: > > > > On Fri, Jan 3, 2020 at 2:43 PM Cong Wang wrote: > > > > > > On Wed, Jan 1, 2020 at 7:41 PM Jim Meyering wrote: > > > > &g

  1   2   3   4   5   6   7   8   9   10   >