update about the calendar of Nepal

On 2025-07-15, I wrote: > This is precisely the reason why I did not include support for the > calendar of Nepal (ne_NP locale). When I realized that [1][2][3] > - Different web sites in the .gov.np domain have different > Gregorian to Vikram Samvat conversions, > - People seem to ignore th

Re: git-merge-changelog packaging

e useful. I've now migrated the git-merge-changelog program under the 'vc-changelog' project on Savannah. Accordingly, I'm removing it from Gnulib now: 2025-08-05 Bruno Haible git-merge-changelog: Remove module. It is now available through $ git clone

Re: git-merge-changelog do not re-add ChangeLog entries

Simon Josefsson wrote: > Patrice, is there any chance you could try the latest binary package > from Debian experimental and confirm if it fixes the issue? > ... > There is a small chance we could get Debian trixie to ship with this > fix, and testing helps the release team to make decision. The b

Re: mention git2cl ?

Simon Josefsson wrote: > - gitlog-to-changelog produces nice outputs when the GNU changelog > pattern is used in git commit messages, but I found that git2cl > produces better looking outputs for projects that uses more terse > one-line git commit messages. Git2cl automatically lists the rel

Re: new module 'nlcanon'

ike LIBINTL and LTLIBINTL. 2025-08-04 Bruno Haible nlcanon tests: Fix last commit. * tests/init.sh (setup_): Revert last change. * modules/test-framework-sh (Makefile.am): Augment TESTS_ENVIRONMENT here. * modules/nlcanon-tests (Makefile.am): Don't

Re: git-merge-changelog packaging

Simon Josefsson wrote: > Maybe we could publish 'make dist' tarballs of git-merge-changelog in > the ftp.gnu.org/gnu/gnulib/ area? It doesn't really have to be its own > project, unless I'm missing something. When the 'vc-changelog' project exists and was created for this purpose, why not use it?

new module 'nlcanon'

25-08-04 Bruno Haible nlcanon: Add tests. * tests/test-nlcanon.sh: New file. * modules/nlcanon-tests: New file. * tests/init.sh (setup_): Adjust also top_builddir, if set. nlcanon: New module. * build-aux/nlcanon.sh.in: New file, with a function fun

mention git2cl ?

Hi Simon, Does the 'git2cl' program have any functional advantage over the two similar modules in Gnulib [1][2]? Should we mention it as an alternative in the documentation? Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/VCS-To-ChangeLog.html [2] https://www.gnu.org/software/gnu

Re: git-merge-changelog packaging

Collin Funk wrote: > I wonder if it is worth making git-merge-changelog it's own package. It > is also packaged in FreeBSD and Fedora [1][2]. It's also packaged in some more distros, but not many [1]. I've created this Savannah project for it a long time ago: [2] but never found the time to actual

Re: git-merge-changelog do not re-add ChangeLog entries

Simon Josefsson wrote: > I most likely ran into the same problem you > noticed.. so thanks for following through with a bug report. I'll see > if I'm able to set it up and use it once this has been confirmed fixed. For yourself, I'd recommend to use the newest code from gnulib master HEAD, since

Re: bug#79139: cp --reflink truncates sparse files on ZFS

Paul Eggert wrote: > +# if defined __GLIBC__ && ! (2 < __GLIBC__ + (43 <= __GLIBC_MINOR__)) This line is mis-indented. > + /* Work around glibc bug 33245 It would be good to document the workaround in doc/glibc-functions/copy_file_range.texi. Collin Funk wrote: > Can't we make this condi

Re: vma-iter, sigsegv: Use new ioctl available in Linux >= 6.11

PS: The rationale of that new ioctl can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed5d583a88a9207b866c14ba834984c6f3c51d23

Re: nproc honoring cgroup limits

Pádraig Brady wrote: > cgroup constraints are a popular mechanism on linux. > I was thinking of augmenting the nproc routines > to incorporate cgroup cpu constraints for NPROC_CURRENT_OVERRIDABLE > so that we'd return MIN(cgroup constraint, current value); Sounds reasonable. So, if I understand i

vma-iter, sigsegv: Use new ioctl available in Linux >= 6.11

re here are two patches that make the 'vma-iter' and 'sigsegv' modules use this new ioctl() when available. 2025-08-01 Bruno Haible sigsegv: Use new ioctl available in Linux >= 6.11. * lib/stackvma.c: On Linux, include , . (vma_iterate_procmap_quer

Re: nstrftime: Handle non-Gregorian calendars the same way on all platforms

Collin Funk wrote: > > Collin: With this patch, the three coreutils tests now fail on OpenBSD the > > same > > way as they fail on macOS > > . > > This means, you can use gdb on OpenBSD to debug it. > > I'll just respond here since it is mostl

Re: git-merge-changelog do not re-add ChangeLog entries

Patrice Dumas wrote: > I think that it is better to > generate the commit message form the ChangeLog instead of the other way > around because it is easy to have only a git log and nothing in the > ChangeLog, and because it is much easier to edit a ChangeLog rather than > edit the git history. Som

nstrftime: Handle non-Gregorian calendars the same way on all platforms

sts now fail on OpenBSD the same way as they fail on macOS <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79118>. This means, you can use gdb on OpenBSD to debug it. 2025-07-29 Bruno Haible nstrftime: Handle non-Gregorian calendars the same way on all platforms. Suggested by Colli

git-merge-changelog: Fix upstream/downstream heuristic for "git pull"

the modified ChangeLog with other people's entries is more likely "upstream". - Starting with git 2.44, git provides a placeholder "%Y" that can be used to disambiguate the remaining cases. 2025-07-29 Bruno Haible git-merge-changelog: Fix upstream/down

javacomp: Fix memory leak

This patch fixes a small memory leak in the 'javacomp' module. 2025-07-29 Bruno Haible javacomp: Fix memory leak. * lib/javacomp.c (execute_and_read_line): Free the line after getline() failed. diff --git a/lib/javacomp.c b/lib/javacomp.c index 936cf79810..

Re: git-merge-changelog do not re-add ChangeLog entries

025-07-29 Bruno Haible git-merge-changelog: Fix essential functionality (regr. 2023-05-21). Fixes two mistakes in commit a8921605af342b9061e04e18fc952d386e5a071c. Reported by Patrice Dumas in <https://lists.gnu.org/archive/html/bug-gnulib/2025-07/msg0

Re: export VAR=VAL portability

Collin Funk wrote: > Do you think a test for that is worth adding to your > maint-tools/test-programs/sh-features script? I would do it myself, but > don't have an old FreeBSD VM/machine or old bash installs... Done, together with a couple of other shell portability problems. Bruno

Re: git-merge-changelog do not re-add ChangeLog entries

Patrice Dumas wrote: > > * What if you build git-merge-changelog yourself (using the build > > instructions > > at the top of gnulib/lib/git-merge-changelog.c), instead of relying on the > > build from your distro? > > I tried and it was better, my ChangeLog entry did not disappear. It was

Re: Recommendations for gnulib-tool --copy-file

Hi Marc, Marc Nieper-Wißkirchen asked: > What is the suggested workflow for "gnulib-tool --copy-file", > described in chapter 20 of the manual? Am I supposed to add the copied > file under version control so that a fresh checkout works out of the > box? While some packages may do that, the main u

Re: git-merge-changelog do not re-add ChangeLog entries

Hi Patrice, > Yes they really disappeared. You can see it with the following commits > in Texinfo: > > I did these two commits, each originally with its ChangeLog entry (you > can see that with the logs, they are automatically generated based on > the CHangeLog last entry): > https://cgit.git.sa

Re: posixtm tests: Avoid test failure on Haiku.

Collin Funk wrote: > A few tests from tests/test-posixtm.c fail on Haiku. These are the same > as what fail on other platforms. I assume this means the time string > cannot fit into 'struct tm' or 'time_t' on these platforms, not a bug in > Gnulib's code. > > Therefore, I pushed the attached patch

Re: sethostname tests: Avoid test failure on Haiku.

Collin Funk wrote: > I reported it to the Haiku tracker [1]. > [1] https://dev.haiku-os.org/ticket/19692 Thanks!

Re: git-merge-changelog do not re-add ChangeLog entries

Hi Patrice, > [merge "merge-changelog"] > name = GNU-style ChangeLog merge driver > driver = /usr/bin/git-merge-changelog %O %A %B > > There is also the expected line in .gitattributes. I have essentially the same config. > Typically I make some changes with changes in top of Change

Re: run-test: script for running tests under valgrind

> > > I wonder why the script doesn't use the "libtool --mode execute > > > valgrind ..." approach And also because when there is a bug, and the developer wants to debug it using gdb, it's so much easier to run gdb testcase than ../libtool --mode=execute gdb testcase > > Because we don't know

Re: run-test: script for running tests under valgrind

u would run "make check", and that would succeed, despite the memory errors. This patch corrects the suggestion: 2025-07-23 Bruno Haible run-test: Suggest a more reliable way of invoking valgrind. * build-aux/run-test (func_usage): Suggest to use the --error-exit

Re: thrd: Fix -Wincompatible-pointer-types on AIX 7.3.

lation error, but would still have undefined behaviour (and the clang UBSAN actually crashes upon function pointer type conversion). I'm committing this patch instead. It's a little more ugly, but no undefined behaviour. Tested on both AIX 7.1 and AIX 7.3. Bruno 2025-07-23 Bruno Ha

Re: FLUSH_ALL

Paul Eggert wrote: > The other, in lib/textstyle.in.h, > seems to be a performance bug - at least, the description of FLUSH_ALL > doesn't explain the sometimes-severe performance issues involved, which > leads me to be puzzled about what's intended. The comments: /* Flushes buffers in the cu

Re: sys_un-h: Make sure that the 'sys' subdirectory is created.

Collin Funk wrote: > $ gnulib-tool --list | grep -- '-h$' | xargs gnulib-tool \ > --create-megatestdir --dir testdir-all > $ cd testdir-all && ./configure && make -j 4 V=0 That's an interesting test recipe :) > Fixed with the attached patch. Looks good. Thanks! Bruno

Re: stdioext: Port to recent OpenBSD snapshots with an incomplete FILE type.

Collin Funk wrote: > I tested a testdir of all modules on an OpenBSD snapshot from 2025-07-19 To complement this, I did the same thing on i386 (32-bit install). All tests pass. Bruno

Re: stdioext: Port to recent OpenBSD snapshots with an incomplete FILE type.

Hi Collin, > >> Do you want to deal with it, or should I ? > > > > I'll take a look later today. > > I pushed the attached patch which fixes it. That's great! Thanks a lot. > It is much simpler than I expected since most of the Android code can be > reused for OpenBSD. I know Bionic uses a lot

Re: commit signing

Arsen Arsenović wrote: > The signature is not a signature of the author, > it's the signature of the committer. Oh, that explains why commit signing is useful in the Linux kernel project, - with the lieutenants and the subsystem maintainers, that commit and forward patches from individual co

Re: FILE is now an incomplete type on OpenBSD.

Hi Collin, > I just saw this change in OpenBSD making FILE an incomplete type [1]. > GitHub mirror since I do not know CVS very well [2]. > > I assume that this change will require some changes to the stdio_ext.h > functions along with some others maybe like fflush. Therefore, I figured > it was

Re: doc: Document resilience against supply chain attacks

Jeffrey Walton wrote: > You should probably mention ... signing tarballs. GNU tarballs, distributed on ftp.gnu.org, are signed with an OpenPGP or LibrePGP key, yes. But since Gnulib is normally not downloaded from there, but from its git repo, tarball signing is not relevant here. > If you rely

Re: commit signing

Jeffrey Walton wrote: > You should probably mention commit signing Why should we mention this? The Gnulib repository doesn't use signed commits. And IMO it doesn't need to. Last time we discussed this, IIRC Simon noted that enforcing signed commits hampers development by causing hassles to the de

Re: [PATCH] bootstrap: Use gnulib-tool from PATH if available.

Maxim Cournoyer wrote: > There's no /bin/sh in the Guix build container, for example. I see. You'll have to patch *many* scripts, in many packages, to accommodate that choice. And you can't upstream these changes, because the difference between build-aux/git-version-gen ... and sh build-aux/

Re: epsf.tex: New file

Simon Josefsson wrote: > Right. I would say that the days of the DVI and PS formats are probably > long gone, and definitely as a default format. PDF has won. DVI yes. PS has its use 1. as alternate format, at least in arXiv.org, 2. as easy-to-create vector graphics format. > I tried to fin

Re: next-prime: Revert to original behaviour in GNU gettext

> 2025-07-15 Bruno Haible > > next-prime tests: Update unit test after last change. > * tests/test-next-prime.c (main): Allow either behaviour. Oops. It turns out that - is_prime (3) returns false, leading to next_prime (3) = 5. - the unit test fails because next_p

Re: README-release and Hydra

Collin Funk wrote: > [3] https://cgit.git.savannah.gnu.org/cgit/hydra-recipes.git The coreutils recipe is unmaintained since 2018, and the gettext recipe since 2015. I think it's safe to remove that paragraph. Bruno

Re: epsf.tex: New file

Simon Josefsson wrote: > > On a Debian or Ubuntu system with the packages > > texinfo texlive-base texlive-latex-base > large cost for a small benefit. > The cost is installing all of texlive for each and every CI/CD job. As said above, one doesn't need "all of texlive". Only texlive-base and te

Re: nstrftime: Add support for non-Gregorian calendars

file as well: 2025-07-17 Bruno Haible parse-datetime: Update documentation regarding non-Gregorian calendars. * doc/parse-datetime.texi (General date syntax): Mention that date syntax should use the Gregorian calendar. Change examples that use %Y to use LC_ALL

Re: sb_xdupfree and empty strings

very least. That's definitely a bug. Thanks for finding it! Fixed as follows. 2025-07-17 Bruno Haible Fix sb_dupfree(), sbr_dupfree() on an empty buffer. Reported by Marc Nieper-Wißkirchen at <https://lists.gnu.org/archive/html/bug-gnulib/2025-07/msg00119.htm

Re: doc: Use @code around errno constants.

Collin Funk wrote: > From reading the description of @samp and @code in the Texinfo manual > [1] [2], @code seems more correct, in my opinion. I agree. > Fixed with the attached patch. Thanks! Bruno

Re: typedef for struct string_buffer?

Marc Nieper-Wißkirchen wrote: > My main point, however, was more about the consistency; > gl_list_iterator_t, for example, hides a quite large structure. In gl_list.h, there are 3 pointer types (some with 'const') and 1 non-pointer type. The typedefs are there to simplify the API for the programme

Re: [PATCH] bootstrap: Use gnulib-tool from PATH if available.

Hi Maxim, > Some distributions such as GNU Guix include in their package for > gnulib a 'gnulib-tool' command under their $bindir > prefix (e.g. '/bin') for users to use, along the unmodified full > sources. And this package is [1] from 2024-05-30 and therefore unsupported. The Gnulib manual sta

Re: typedef for struct string_buffer?

Hi Marc, > > The only benefit that I see is that the typedef name is usually shorter > > to write. But that does not matter when, typically, there will be 1 or > > at most 2 instances of such a struct in a given function. > > The related module string-desc exports the typedefs string_desc_t and >

Re: *_t namespace

> > (*) Unfortunately, they often use the POSIX-reserved "_t" namespace, > > but that's a different issue. > > I used to feel the same way, but other namespaces for types end up being > ugly. For example, I think vim uses "*_T". Well. The *_t convention is used 20 times more frequently than the o

Re: nstrftime: Add support for non-Gregorian calendars

Collin Funk wrote: > As you mentioned, in Thailand the Gregorian calendar is used alongside > the Thai solar calendar (even if it is used less so in day-to-day life). Yes, what does *not* matter, IMO, for the 'date' program is use in religious life (as opposed to official and everyday civil life)

Re: nstrftime: Add support for non-Gregorian calendars

Paul Eggert wrote: > > For Iran, there is an authoritative source (some institute at the > > university of Teheran), cited by the wikipedia page [4] that gives the > > complete list of leap years for the time period that we are interested > > in (1925 to 2100). > > That list of years says it was c

Re: lib/unictype/bitmap.h: wrong casting of "table..."

Bjarni Ingi Gislason wrote: > static inline int > bitmap_lookup (const void *table, ucs4_t uc) > { > unsigned int index1 = uc >> header_0; > if (index1 < ((const int *) table)[0]) > ... > unsigned int lookup3 = ((const unsigned int *) table)[lookup2 + > index3]; This is all corr

Re: nstrftime: Add support for non-Gregorian calendars

Pádraig Brady wrote: > > Or do you mean, checking some calendar specific properties? Like > > that the year in the Ethiopian calendar is either 7 or 8 years behind > > the year in the Gregorian calendar? > > Right. Some checks like latter, that I could add to the coreutils test suite. > No worries

Re: nstrftime: Add support for non-Gregorian calendars

Hi Paul, > I'm dubious about supporting astronomical calendars, because any > algorithm we use to calculate them will be "wrong" in some sense. This is precisely the reason why I did not include support for the calendar of Nepal (ne_NP locale). When I realized that [1][2][3] - Different web si

Re: nstrftime: Add support for non-Gregorian calendars

Hi Pádraig, > Off the top of your head might there be any platform general tests > that could be added to coreutils? I'm not sure what you mean. I checked the conversions for consistency with what ICU does, and except for one difference [1] it seems to be consistent. But I don't think you would

Re: xsd_copy

Marc Nieper-Wißkirchen wrote: > It would also be nice to have a public function that does xsd_copy > (sd_new_addr (len, addr)) (and also a non-x version of that). There's a trade-off when adding "nice" but redundant functions to an API: It makes the programmer's learning curve longer, and it also

Re: typedef for struct string_buffer?

Hi Marc, > Many if not the majority of Gnulib modules provide typedefs for the > public structs they export (*). It just occurred to me that the > (x)string-buffer module does not provide any typedef for its struct > string_buffer. > > Was this an oversight or on purpose? What would be the benef

nstrftime: Add support for non-Gregorian calendars

ode is careful not to mix Gregorian time elements (in 'struct tm') with non-Gregorian time elements (in 'struct calendar_date'). Pádraig, you may add something like the following as a coreutils/NEWS entry: 'date' now outputs dates in the country's nati

nstrftime: Remove old comment about OSF/1

OSF/1 (Tru64) is long obsolete. No need to mention it any more. This patch simplifies the code accordingly. 2025-07-15 Bruno Haible nstrftime: Remove old comment about OSF/1. * lib/strftime.c (MULTIBYTE_IS_FORMAT_SAFE): Define to 1 always. diff --git a/lib/strftime.c b/lib

localename-unsafe-limited: Extend to more platforms

pendencies are not large. And similarly for the 'localename-unsafe-limited' module. The added dependencies here: localename-environ, strdup, windows-mutex. That's not a lot; especially not generic multithreading. 2025-07-15 Bruno Haible localename-unsafe-limited

getlocalename_l-unsafe-limited: Extend to more platforms

e. 2025-07-15 Bruno Haible getlocalename_l-unsafe-limited: Extend to more platforms. * modules/getlocalename_l-unsafe-limited (Description): Update platforms list. (Files): Add m4/intl-thread-locale.m4. (Depends-on): Add setlocale-fixes. (config

getlocalename_l-unsafe: Make configuration more robust

A small bug fix: The macro gl_FUNC_GETLOCALENAME_L_UNSAFE may set the value of HAVE_GETLOCALENAME_L and REPLACE_GETLOCALENAME_L. Therefore we need to make sure that it does not get invoked/expanded before gl_LOCALE_H_DEFAULTS. 2025-07-15 Bruno Haible getlocalename_l-unsafe: Make

localename-unsafe: Reduce dependencies

The module 'localename-unsafe' needs locking only on native Windows. This makes it possible to reduce the dependencies of the module. 2025-07-15 Bruno Haible localename-unsafe: Reduce dependencies. * lib/localename-unsafe.c: Include windows-mutex.h instead of

Re: next-prime: Revert to original behaviour in GNU gettext

> 2025-07-12 Bruno Haible > > next-prime: Revert to original behaviour in GNU gettext. > Reported by Rocket Aaron at > <https://savannah.gnu.org/bugs/?67305>. > * lib/next-prime.c (next_prime): In GNU gettext, don't skip small >

epsf.tex: New file

'texlive-plain-generic' package: https://packages.debian.org/bookworm/texlive-plain-generic But that package is 66 MB large, which is overkill for a single file. Since we distribute texinfo.tex through Gnulib, for developers' convenience, we should do the same for epsf.tex.

javacomp-script, javacomp: Remove support for javac versions < 1.8

his change already a year ago. But it's tiresome to make the same change in all packages; it's better to make it centrally in Gnulib. Done through the following patch: 2025-07-13 Bruno Haible javacomp-script, javacomp: Remove support for javac versions < 1.8.

Re: safe-alloc: Does REALLOC_N leak if reallocation fails?

Paul Eggert wrote: > This module never caught on. Indeed, according to our database [1], only the packages augeas netcf use this module. Bruno [1] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=used-modules

Re: obstack-printf: Fix memory overrun on glibc systems

> Compiling GNU Bison (HEAD~10) with the newest gnulib, and running "make > check", > I get 8 test failures: > testsuite: 608 615 619 620 622 623 625 626 failed > Seen on Ubuntu 22.04 and on Ubuntu 24.04 with gcc 13. > > Same of the failures are caused by SIGSEGV, some by SIGABRT: Different sy

next-prime: Revert to original behaviour in GNU gettext

When I created the module 'next-prime' two months ago, to unify code from Gnulib and from GNU gettext, it had the side effect of changing the size of small .mo files. This is undesired; therefore this patch reverts to the original definition of next_prime within GNU gettext. 2025-07

obstack-printf: Fix memory overrun on glibc systems

nt layouts of 'struct obstack' or by different calling conventions of _obstack_newchunk. The incompatibility needs to be avoided. This patch does it, and it fixes all of the 8 test failures. 2025-07-12 Bruno Haible obstack-printf: Fix memory overrun on glibc systems.

Re: Many Gnulib errors on Cygwin trying to build Bison from source

Z. Majeed wrote: > Spotting the diff was trivial - it's caused by an idempotency check for > stddef.h that was added to gnulib in commit e529f4f on 8 April 2025 (Workaround to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870 ) I see. Yes, this explains why (with the bison state as of two day

Re: Many Gnulib errors on Cygwin trying to build Bison from source

Z. Majeed wrote: > This is the latest cygwin I'm using - is it exactly the version you tried? > uname -r > 3.6.3-1.x86_64 Yes, same for me. > with gcc version16.0.0 20250706 (experimental) I use gcc 11.5.0 there. A gcc version >= 15 can indeed make a difference in theory (configure tests produc

Re: [PATCH] ftoastr: suggest a better algorithm

Paul Eggert wrote: > + Adams U. Ryū: fast float-to-string conversion. > + PLDI 2018. 270–282. . */ For the 'float' and 'double' types, we could indeed use this code in Gnulib (copying the code from https://github.com/ulfjack/ryu, which can be redis

Re: Many Gnulib errors on Cygwin trying to build Bison from source

Z. Majeed wrote: > Here are the steps I followed > git clone --single-branch git://git.savannah.gnu.org/bison master > > git worktree add -b master.old ../master.old 4ff0741 > HEAD is now at 4ff0741f maint: make update-copyright > > git submodule update --init --recursive > ./bootstrap > git subm

Re: string-h: Fix compilation error on macOS with fortify

Hi Simon, > > Thanks for the report. This patch should fix it. > > I was just about debugging this myself, it happens on Windows MSYS too: Glad that I did a general fix. My first attempt was to conditionalize on (defined __APPLE__ && defined __MACH__ && _USE_FORTIFY_LEVEL != 0)... > Once you pu

Re: Many Gnulib errors on Cygwin trying to build Bison from source

Z. Majeed wrote: > 1. The errors begin with This is not a bug report. A proper bug report MUST state two things: 1) What did you do? (Which git repository did you clone? Which commands did you issue to build the thing? What were the settings of relevant environment variables like

string-h: Fix compilation error on macOS with fortify

^~ > ... > > > The issue seems to be that macOS uses defines to redirect these functions to > _chk versions. When that define gets expanded in these new gnulib lines, > everything breaks. Thanks for the report. This patch should fix it. 2025-07-10 Bruno Haible

Re: regexprops-generic propagation

Bernhard Voelker wrote: > still it can take some months sometimes from a change in regex.h > until updating the gnulib submodule in findutils ... Oh, so a change in regex.h (in gnulib) propagates to a change in regexprops-generic.texi (in gnulib) via some tool that lives in the findutils repositor

Re: regexprops-generic propagation

Bernhard Voelker wrote: > * [PATCH 2/3] regexprops: sort regex_map alphabetically >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=c9c2c511759 > > * [PATCH 3/3] doc: regenerate regexprops.texi >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=facc27e1804 > > 2. Commit (

Re: GCC w/ C23 changes LDBL_EPSILON of IBM long double, causes test-float-h to fail

Paul Eggert wrote: > -/* LDBL_MAX is represented as { 0x7FEF, 0x, 0x7C8F, > 0x }. > ... > +/* LDBL_MAX is 2**1024 - 2**918, represented as: { 0x7FEF, 0x, > + 0x7C9F, 0x }. You are right. I don't know

Re: stdcountof-h: Add reminder to include .

Collin Funk wrote: > I accidentally ran 'make check' in Gnulib (wrong terminal window), but > it ended up being useful. I saw: > > File lib/options.h lacks a config.h reminder. Needed for: _GL_GNUC_PREREQ > File lib/stdcountof.in.h lacks a config.h reminder. Needed for: > _GL_GNUC_PREREQ

Re: GCC w/ C23 changes LDBL_EPSILON of IBM long double, causes test-float-h to fail

sure that Gnulib provides the ISO C 23 compliant value on all PowerPC platforms, regardless of compiler version. 2025-07-07 Bruno Haible float-h: Enforce the ISO C 23 compliant value for LDBL_EPSILON. Reported by Cosima Neidahl in <https://lists.gnu.org/archive/htm

Re: vasnprintf: Silence -Wswitch-unreachable warning.

case 'a': case 'A': pad_ourselves = 1; break; # endif default: pad_ourselves = prec_ourselves | group_ourselves; break; } The advantage would be one less

Re: pagealign_alloc: Don't assume pointers fit in 'unsigned long'.

Collin Funk wrote: > Thanks for checking. I pushed the attached patch with those changes. Thanks. > I assumed uintptr_t was correct for performing arithmetic on any > pointer. I know CHERI has some limitations, but I am not familiar with > them. Perhaps I will get around to reading the manual at

Re: pagealign_alloc: Don't assume pointers fit in 'unsigned long'.

Hi Collin, > However, I think that the correct way to write this would be to use > 'uintptr_t' which would work with large page sizes on more niche > architectures [1]. Yes, the way to get rid of the warning is to cast from pointer to 'uintptr_t', not 'unsigned long'. > Can you check the attache

Re: strptime: Convert K&R definitions to ANSI C.

Collin Funk wrote: > The lib/strptime.c file uses K&R definitions. When built with a recent > GCC release one will see -Wold-style-definition warnings. > ... > Therefore, I have pushed the attached patch. Thanks. Good to see that it is consistent with glibc commit 80d9be8122d1fe181d2476b5dad9f4ce3

Re: strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16).

Collin Funk wrote: > Fixed with the attached patches. Thanks!

Re: strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16).

Hi Collin, > I've pushed the 2 attached patches fixing a minor bug in your > strn?casecmp_l implementations from a few months ago. > > On systems where Gnulib defines a locale_t, we need to include > c-strcase.h for the c_strn?casecmp functions, which are used if the > given locale is the C local

new stable branch

I created a new stable branch, made the doc change below, and re-published the documentation. 2025-07-01 Bruno Haible doc: Update regarding stable branches. * doc/gnulib-readme.texi (Stable Branches): Mention new branch stable-202507. Mention that stable-202407 is no

Re: [PATCH] openat-die: pacify Apple clang-1400.0.29.202

Hi Paul, > > my patch from 2025-05-28 > > https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00266.html > > Oh, it seems that coreutils doesn't have that fix yet. I reverted the > Gnulib openat-die patches. Thanks. > > 2) Do we care about random warnings on non-GNU systems? > > Not usua

Re: [PATCH] openat-die: pacify Apple clang-1400.0.29.202

Hi Paul, > diff --git a/lib/openat-die.c b/lib/openat-die.c > index 79a5b23bc8..f72ed0537b 100644 > --- a/lib/openat-die.c > +++ b/lib/openat-die.c > @@ -34,7 +34,7 @@ _Noreturn void > openat_save_fail (int errnum) > { > #ifndef GNULIB_LIBPOSIX > - error (exit_failure, errnum, > + error (exit

Re: new module 'options'

The unit tests fail to link on *BSD and other platforms. This patch should fix it: 2025-06-30 Bruno Haible options tests: Fix link error. * modules/options (Link): New section. * modules/options-tests (Makefile.am): Link test-options and test-options-prog with

Re: [PATCH] _Noreturn: pacify gcc -std=gnu99 -Wpedantic

, void, (void)); | ^~~~ gmake[4]: *** [Makefile:27318: test-assert-h-c++.o] Error 1 This patch fixes it. Was there any reason to remove the '(!defined __cplusplus || defined __clang__) && ' part of the condition? 2025-06-30 Bruno Haible _Noreturn

Re: move kwset to gnulib?

> 2025-06-25 Bruno Haible > > kwset: Add tests. > * lib/kwset.c (kwsexec): Correct documentation. > * tests/test-kwset.c: New file. > * modules/kwset-tests: New file. The CI reports a link error on macOS, FreeBSD, NetBSD, OpenBSD, Cygwin. This p

Re: new module 'options'

Additionally, there's a problem on mingw, when using --enable-shared: The value of 'optind' that the main() program sees is always 1. This patch fixes it. 2025-06-29 Bruno Haible options: Support use in a shared library on mingw. * lib/options.h (_gl_get_ne

Re: new module 'options'

;show_version, 1 }, }; * Use a variadic macro that provides the missing initializers: static struct program_option const options[] = { OPTION( "width", 'w', required_argument ), OPTION( NULL, 'x', no_argument ), OP

Re: gnupload: Remove checks for gpg2.

Hi Collin, > I cannot recall the last time I used a system where the 'gpg' command > was version 1. The cfarm CentOS 7 machines even have 'gpg' as version 2, > and those are probably the oldest I have access to. > > Any objections to the attached patch? > > In 2018 you said [1]: > > > Ubuntu

Re: new module 'options'

Antonio Diaz Diaz wrote: > The use of 'countof' instead of terminating the array of 'struct > program_option' with an element containing all zeros may be an obstacle for > the adoption of this API outside Gnulib. Yes, I agree. If we ever want to move this functionality to glibc, either the array

new module 'options'

[1]. Compared to yesterday's draft, I - changed the allocation of the arrays from 'static' to stack-allocated, - added a test suite, - fixed a bug. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=7e161bef0bc9d5ea5e6f3dd490ecd5da6f642671 2025-06-27 Bruno Haible

  1   2   3   4   5   6   7   8   9   10   >