Re: move kwset to gnulib?

Collin Funk wrote: > You already probably thought about this, but just to be sure. In > kwset.[ch]: > > /* Written August 1989 by Mike Haertel. */ > > Is it okay to move it to Gnulib since Grep is assigned to the FSF? Yes, the copyright has already been assigned to the FSF. The only imagina

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

7; in the future. If so, I expect glibc and others to > change this in the future. I hope this will happen, in the long run. Can't guarantee it. But where I can I want to see warnings for confusion-introducing code like char *s = gettext ("foo"); 2025-06-01 Bruno Ha

move kwset to gnulib?

The files kwset.[ch] from GNU grep are also used in GNU gettext (and some other non-GNU packages, e.g. 'git'). Paul, Jim: Would it be OK to move them to a Gnulib module? I would like to eliminate future updates of this code from the gettext maintenance, i.e. make them automatic via gnulib-tool.

stat-time: Fix syntax errors in C++ mode on MSVC

x27;{' ../../gltests/../gllib\stat-time.h(205): error C2447: '{': missing function header (old-style formal list?) ../../gltests/../gllib\stat-time.h(240): error C2059: syntax error: '}' ../../gltests/../gllib\stat-time.h(240): error C2143: syntax error: missing ';&#x

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

I wrote: > 2025-05-28 Bruno Haible > > gettext-h: Avoid gcc -Wformat-security warnings with --disable-nls. Oops, this causes compilation errors on Solaris 11: In file included from ../../gltests/xalloc-die.c:28: ../../gltests/gettext.h:69:1: error: conflicting types for ‘gette

Re: AC_CHECK_DECL has wrong results on macOS

onnull __l) __INTRODUCED_IN(26); wctrans_t _Nonnull wctrans_l(const char* _Nonnull __name, locale_t _Nonnull __l) __INTRODUCED_IN(26); #endif /* __ANDROID_API__ >= 26 */ 2025-05-31 Bruno Haible Make gl_CHECK_FUNCS_MACOS work with current unreleased Autoconf. Reported by Paul Egg

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Holger Hoffstätte wrote: > It does indeed work with gcc-15, but not with clang: With clang, you're out of luck. clang's -Wformat-security does not know about the gettext(), dgettext(), dcgettext() functions. Bruno

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Collin Funk wrote: > The issue is that __attribute__ ((__format (...))) adds a check to make > the format string is actually a string. When it sees a call to 'gettext' > it assumes that it can return NULL which will cause issues as a format > string. How can that be? Before the fix that I just com

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

ion checking of 'msgfmt -c'. Then it is irrelevant whether a format string takes 0 parameters or a positive number of parameters. Thus the "and no format arguments" part of the warning is pointless when it comes to *gettext invocations. This patch fixes the warnings. 2025-05

Re: vasnprintf: Fix uninitialized values.

Hi Collin, > ./vasnprintf.c:6203:49: warning: variable 'thousep_len' is used > uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] > 6203 | if ((flags & > FLAG_GROUP) && (intpart_digits > 1)) > |

stddef-h: Make 'unreachable' usable in C++ mode

able' available from also in C++ mode. But without creating a conflict with 'unreachable' defined in C++ (cf. <https://en.cppreference.com/w/cpp/utility/unreachable>). This patch does it. 2025-05-27 Bruno Haible stddef-h: Make 'unreachable' u

Re: making good use of LLMs

Paul Eggert wrote: > I just asked Gemini (2.5 Flash) that question ... > >volatile sig_atomic_t in_signal_handler = 0; >void my_signal_handler(int signum) { >in_signal_handler = 1; >} :-D A perfect example for junior programmers why they should keep their brain turned on when

Re: making good use of LLMs

Paul Eggert wrote: > > They are also not defined on AIX 7.3 (cfarm119.cfarm.net). > > Thanks for fixing all that. I was lazily relying on Google searches and > Gemini, not the real thing. Welcome to the new technologies :) IMO there are two considerations when using a prior knowledge summarizat

Re: strchrnul: Update doc

> macOS 15.4 added the strchrnul() function in libc. [1] Here's an improvement for users of the newest macOS SDK (that includes the header files of macOS 15.4) on older macOS versions (< 15.4). 2025-05-27 Bruno Haible strchrnul: Fix for users of the curren

Re: [PATCH 2/3] fcntl-h: support O_DIRECTORY

working fcntl.h... no (bad O_NOATIME) on Mac OS X 10.5 and AIX 7.1 (cfarm111.cfarm.net). - Cygwin 1.5.x did not have it, see https://cygwin.com/cygwin-ug-net/ov-new.html 2025-05-27 Bruno Haible fcntl-h: Update platforms list re O_DIRECTORY. * doc/posix-headers/fcn

Re: [PATCH 3/3] fcntl-h: document O_CLOFORK etc

mingw, MSVC 14. They are also not defined on AIX 7.3 (cfarm119.cfarm.net). Only Solaris 11.4 has these macros, so far. 2025-05-27 Bruno Haible doc: Update platforms list re *_CLOFORK. * doc/posix-headers/fcntl.texi: Update platforms list. diff --git a/doc/posix-headers/fcntl.t

Re: [PATCH 1/3] Document HAVE_WORKING_O_NO{ATIME,FOLLOW}

A small styling tweak: 2025-05-27 Bruno Haible doc: Style module name. * doc/posix-headers/fcntl.texi: Style module name with @code. diff --git a/doc/posix-headers/fcntl.texi b/doc/posix-headers/fcntl.texi index 8d018b9aa6..22e791b5a8 100644 --- a/doc/posix-headers

Re: crypto/gc: Pacify -Wformat warnings.

Hi Collin, > In a testdir of all crypto modules: > > CC gc-gnulib.o Please take the habit to show the compiler command line, not only the summary line. It's important in cases like this because ... > This is harmless, but I like having -Wformat enabled sometimes. ... the option tha

gnulib-tool: Remove build-aux/test-driver.orig from testdirs

'gnulib-tool --create-testdir' creates a file build-aux/test-driver.orig, that is not needed and that creates trouble when one adds the generated testdir in git (because *.orig is typically listed in .gitignore). This patch removes that useless file. 2025-05-26 Bruno Haible

Re: selinux-h: Fix error with MSVC

Collin Funk wrote: > It seems like a good idea to run this on less-common platforms every > once in awhile. > > I thought maybe it was worth adding to CI, but it takes a long-ish time > and I don't think headers break too frequently. Yes, exactly: Once we've fixed the testdirs of all *-h modules,

Re: selinux-h: Fix error with MSVC

Hi Collin, > Wouldn't the following do the same? > > $ gnulib-tool --create-megatestdir --dir testdir1 $(gnulib-tool --list | > grep -- '-h$') That's what I did, yes: $ ./gnulib-tool --create-megatestdir --dir testdir1 --single-configure --with-c++-tests `cd modules && echo *-h` Bruno

stddef-h tests: Add more C++ tests

This patch makes it clear what one can expect from the header in C++ mode. 2025-05-25 Bruno Haible stddef-h tests: Add more C++ tests. * tests/test-stddef-h-c++2.cc: Test the expected contents of . diff --git a/tests/test-stddef-h-c++2.cc b/tests/test-stddef-h-c++2.cc index

selinux-h: Fix error with MSVC

ux.h(87): error C2081: 'mode_t': name in formal parameter list illegal .\selinux/selinux.h(87): error C2146: syntax error: missing ')' before identifier 'm' .\selinux/selinux.h(88): error C2059: syntax error: ')' Fixed as follows. 2025-05-25 Bruno Haib

fcntl-h, unistd-h: Fix errors in C++ mode with MSVC

49): error C2039: '_open': is not a member of '`global namespace'' .\fcntl.h(749): error C2065: '_open': undeclared identifier .\fcntl.h(749): error C2440: 'return': cannot convert from 'int (__cdecl *)(const char *const ,const int,const int)&#x

utime-h: Fix error in C++ mode with MSVC

h(646): note: This conversion requires a reinterpret_cast, a C-style cast or function-style cast make[5]: *** [Makefile:784: test-utime-h-c++.obj] Error 2 This patch fixes it. 2025-05-25 Bruno Haible utime-h: Fix error in C++ mode with MSVC. * lib/utime.in.h (utim

Re: [PATCH 1/3] stdbuf: port better to Mac OS X 10.4.11

Hi Paul, I think this patch series is for coreutils@, not for bug-gnulib@. Bruno

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Collin Funk wrote: > Anyways, pushed the attached patch since the changes were minimal. Thanks a lot!

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Hi, Holger Hoffstätte wrote: > Further inspection & trying to reproduce this in gnulib revealed that > this requires a combination of -Werror=security and --disable-nls. > > To reproduce in gnulib: > > - clone gnulib > > - create a test dir: >./gnulib-tool --create-testdir --symlink --dir m

strchrnul: Update doc

macOS 15.4 added the strchrnul() function in libc. [1] [1] https://github.com/theory/pgenv/issues/93 2025-05-22 Bruno Haible strchrnul: Update doc. * doc/glibc-functions/strchrnul.texi: strchrnul got added in macOS 15.4. diff --git a/doc/glibc-functions/strchrnul.texi b

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Hi Collin, Thanks for working on this. > With GCC 15 and C++26 the result is (*): > > $ ./configure CFLAGS='-std=gnu99' CXXFLAGS='-std=gnu++26' | grep stdckdint > checking for stdckdint.h... yes > checking whether stdckdint.h can be included in C... yes > checking whether stdckdin

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Paul Eggert wrote: > > we have no way of portably setting the compiler flags > > if available. > > That's fine, but Gnulib does have a portable way to see whether the C++ > compiler works properly with . Namely, compile a little > test with the C++ compiler and if that compiles OK, do not > ge

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Paul Eggert wrote: > As the stdckdint.h bug in question is fixed in GCC 15.1, wouldn't it be > better if the Gnulib workaround is used only if the bug is present (GCC > 15.0)? Who said that is was fixed in GCC 15.1 ? I reproduce it with groff HEAD and gnulib HEAD~2 and GCC 15.1.0 (built from sou

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

G. Branden Robinson wrote: > Do you think it would be a good idea to backport these fixes to gnulib's > stable/2025-01 branch? I think that yes, the second patch fits the criteria for stable branches . The next round of st

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Collin Funk wrote: > The immediate fix that comes to mind is using 'g++ -std=gnu23', but > there are 2 issues with this: > > 1. gnulib/m4/std-gnu23.m4 has no code for C++ versions, because no > one interested in C++ has contributed it to Autoconf yet. > 2. Bruno told me that the C++ st

Re: qemu linux-user limitations

Andreas Schwab wrote: > This issue is not related to a qemu-user environment. You can call it a > Debian or Ubuntu bug, but not a qenu-user limitation. Often issues in one software package resurface (= become visible for the user) as an issue in another software package. I agree with you that th

Re: re_node_set_alloc relies on malloc(0) returning non-NULL

Hi Arnold, > This code in regex_internal.c: > > - > static reg_errcode_t > __attribute_warn_unused_result__ > re_node_set_alloc (re_node_set *set, Idx size) > { > set->alloc = size; > set->nelem = 0; > set->elems = re_malloc (Idx, size); > if (__glibc_u

Re: qemu linux-user limitations

Andreas Schwab wrote: > >> >> > - glibc iconv modules are not installed (on Debian/Ubuntu). > >> >> > >> >> How does this have anything to do with qemu? > >> > > >> > It's not a bug in qemu itself. > >> > >> Thus completely irrelevant. > > > > No, it's relevant > > No, it has nothing to do with

Re: qemu linux-user limitations

Andreas Schwab wrote: > >> > - glibc iconv modules are not installed (on Debian/Ubuntu). > >> > >> How does this have anything to do with qemu? > > > > It's not a bug in qemu itself. > > Thus completely irrelevant. No, it's relevant * for m4, because m4 makes indirect use of iconv_open(),

Re: qemu linux-user limitations

Andreas Schwab wrote: > > - glibc iconv modules are not installed (on Debian/Ubuntu). > > How does this have anything to do with qemu? It's not a bug in qemu itself. But it manifests itself as a bug, for all the qemu user-mode users who take their cross environment from the Debian/Ubuntu distro (

unigbrk/u*-grapheme-{next,prev}: Support Indic characters, Emojis, regional indicators

The u*_grapheme_next and u*_grapheme_prev functions were not updated when the Unicode algorithm for grapheme cluster breaks became more complicated due to Indic characters, Emojis and regional indicators. This series of patches fixes that. 2025-05-18 Bruno Haible unigbrk/u*-grapheme

Re: new module 'spin'

Hi Collin, > I ran into this issue recently compiling GNU Guile which does not yet > support C23 compilers which is the default since GCC 15. My solution was > to run './configure CFLAGS='-std=c99''. Why not CFLAGS='-std=gnu99' ? [1] Compiler options like -std=c99 (compilation for ISO C without

some more tests

These patches add some more test cases. 2025-05-17 Bruno Haible cosh: Add more tests. * tests/test-cosh.c: Include , . (main): Add another test case. 2025-05-17 Bruno Haible sinh: Add more tests. * tests/test-sinh.c: Include , . (main

asyncsafe-spin: Fix race conditions

by not invoking sigprocmask() from a signal handler. 2025-05-16 Bruno Haible asyncsafe-spin: Fix race condition on native Windows. * lib/asyncsafe-spin.h (asyncsafe_spin_lock, asyncsafe_spin_unlock): Add from_signal_handler parameter. * lib/a

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

So, in the end, I don't see any better action than to add a comment: 2025-05-16 Bruno Haible pthread-rwlock tests: Add a comment. Reported by Natanael Copa in <https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00164.html>. * tests/test-pthre

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

0.69 s And on Solaris and Cygwin, I don't see a measurable difference either. Bruno >From 3a46de9041b213e838c2654f29aa1e7cc13347cb Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Fri, 16 May 2025 13:15:56 +0200 Subject: [PATCH] pthread-rwlock tests: Attempt to minimize writer sta

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Rich Felker wrote: > No, I'm saying that it's impossible to make a conforming > implementation that prefers writers *in general*, and that, at least > as you've described them, the above two implementstions "prefer > readers" most of the time in the heavily contended case with multiple > readers (a

Re: Stack overflow check does not work with qemu linux-user emulation

Eric Blake wrote: > It could very well be a bug in qemu's user-mode emulation not handling > stack overflow in the same way a native program would do. Definitely. In my experience, qemu's user-mode emulation has the following limitations: - Catching stack overflow is not supported. - ioctl() are n

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

I wrote: > I did a survey of the various behaviours of rwlock implementations [1]. > Find the results there [2]. > [1] > https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=test-programs/pthread-rwlock;h=bc63cb8ee32bf508f0b7daab6f367fd507786a2b;hb=HEAD > [2] > https://g

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Natanael Copa wrote: > So the test is completely meaningless to verify if gettext will work or > not Correct. The only reason that this test is packaged in the gettext tarball is that gettext needs the 'pthread-once' module, and the unit test of the 'pthread-once' module (test-pthread-once2.c) nee

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Rich Felker wrote: > It's using the raw pthread lock and it's completely expected that it > fails with >10 cores since there will always be multiple readers > scheduled and no chance for a writer to run. Yes, that's the phenomenon known as "writer starvation". > This is necessitated by > POSIX rw

new module 'spin'

'asyncsafe-spin' on top of a module 'spin', that implements purely the multithread-safe spin locks. 2025-05-14 Bruno Haible asyncsafe-spin: Rely on module 'spin'. * lib/asyncsafe-spin.h: Include glthread/spin.h. (asyncsafe_spinlock_t,

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Rich Felker wrote: > AFAICT the code is in tests/test-lock.c from the gnulib repo and calls > the gl_rwlock_* functions, which should be using the gnulib condvar > based implementation. Yes, right. Confirmed by looking at "nm test-lock". Bruno

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Natanael Copa wrote: > Note that there are 64 CPU cores. I have only tested with that many cores on > aarch64. You could vary the number of CPU cores using the 'taskset' command. What I see in an Alpine Linux 3.20 / x86_64 VM: $ time taskset -c 0,1,2,3,4,5,6,7 ./test-pthread-rwlock real time 0.

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

Natanael Copa wrote: > > So, you could try to install a different scheduler by default and repeat > > the test. > > It passed with chrt --fifo (I had to do it from outside the LXC container): > > # time chrt --fifo 10 ./test-pthread-rwlock > Starting test_rwlock ... OK > real 0m 33.00s > user 6

Re: qcopy-acl: Fix copying of ACLs on CentOS 7

Paul Eggert wrote: > If > not, perhaps the Gnulib code should stop invoking attr_copy_action, as > in practice xattr.conf does not supply useful information to programs > that want to copy ACLs. Something like the following untested patch, say? > > diff --git a/lib/qcopy-acl.c b/lib/qcopy-acl.c

Re: qcopy-acl: Fix copying of ACLs on CentOS 7

Paul Eggert wrote: > With [4] in place, I guess Pádraig's point is that Bruno's older Gnulib > patch[5] is no longer needed. I just tried that: Reverting this patch: @@ -33,7 +47,12 @@ static int is_attr_permissions (const char *name, struct error_context *ctx) { - return attr_copy_action (n

Re: gettext-tools 0.24.1 test-pthread-rwlock fails on Alpine Linux riscv64

[Dropping bug-gettext from CC.] Natanael Copa wrote: > The test-pthread-rwlock fails on a riscv64 Alpine Linux system with 64 > cpu cores. The test passes on x86_64 and aarch64. > > ... > > Testsuite summary for gettext-

Re: qcopy-acl: Fix copying of ACLs on CentOS 7

Hi Pádraig, > > 2024-07-15 Bruno Haible > > > > qcopy-acl: Fix copying of ACLs on CentOS 7 (regression 2023-01-12). > > * lib/qcopy-acl.c: Include , . > > (XATTR_NAME_NFSV4_ACL, XATTR_NAME_POSIX_ACL_ACCESS, > > XATTR_NAME_POSIX_ACL_DEFAU

doc: Update doc about ACLs on Cygwin.

2025-05-12 Bruno Haible doc: Update doc about ACLs on Cygwin. * doc/acl-resources.txt: Update function list for Cygwin >= 2.5. diff --git a/doc/acl-resources.txt b/doc/acl-resources.txt index da66e69b60..7b3ae5078e 100644 --- a/doc/acl-resources.txt +++ b/doc/acl-resources.

Re: [PATCH] qcopy-acl: port better to NFSv4 on GNU/Linux

ake: Fatal error: Command failed for target `file-has-acl.o' and likewise on Solaris 11 OmniOS. This patch fixes it. 2025-05-12 Bruno Haible file-has-acl: Fix compilation error on Solaris (regression 2025-05-09). * lib/file-has-acl.c (acl_get_fdfile): Don't define

Re: [PATCH 2/2] obstack: avoid undefined pointer comparison

): error C2065: 'OBSTACK_CPTR': undeclared identifier D:\a\ci-testdir-check\ci-testdir-check\testdir-all\gllib\bitset\table.c(1167): error C2064: term does not evaluate to a function taking 0 arguments make[4]: *** [Makefile:12048: bitset/table.obj] Error 2 This patch fixes it.

doc: Update for a few recently fixed Hurd bugs

A few Hurd bugs were fixed recently. (Thanks Collin for having reported them!) We can update the doc accordingly. 2025-05-12 Bruno Haible doc: Update for a few recently fixed Hurd bugs. * doc/posix-functions/utimensat.texi: List the affected glibc versions. * doc

Re: fts: Fix redefinition of __THROW.

Collin Funk wrote: > > What I propose is to have fts.in.h being preprocessed into fts_.h. > > So that > > - we follow the naming scheme *.in.h of other header files in gnulib, > > - packages like coreutils and findutils are not broken. > > Sure. I pushed the attached patch to do that. Thanks!

string-h, wchar-h: Fix some g++ -Wsystem-headers warnings

n of 'int wcsncmp(const wchar_t*, const wchar_t*, size_t)' has a different exception specifier ../gllib/wchar.h:841:23: warning: declaration of 'wchar_t* wmemset(wchar_t*, wchar_t, size_t)' has a different exception specifier This patch fixes them. 2025-05-11 Bruno Haible

qsort-tests: Fix a clang -Wpedantic warning

clang gives this -Wpedantic warning: test-qsort.c:27:3: warning: void function 'lib_qsort' should not return void expression This patch fixes it. 2025-05-11 Bruno Haible qsort-tests: Fix a clang -Wpedantic warning. * tests/test-qsort.c (lib_qsort): Remove a

Silence some more gcc 15 -Wunterminated-string-initialization warnings

es NUL terminator but destination lacks 'nonstring' attribute (7 chars into 6 available) The third patch in this patch series fixes them. 2025-05-11 Bruno Haible Silence some more gcc 15 -Wunterminated-string-initialization warnings. * lib/uninorm/composition.c

Re: fts: Fix redefinition of __THROW.

Collin, > But having fts_.in.h generate fts.h feels strange to me. > > Jim, what do you think about renaming the file to fts.in.h which > generates fts.h? Neither of these two is what I propose for the short term. What I propose is to have fts.in.h being preprocessed into fts_.h. So that - we

Re: fts: Fix redefinition of __THROW.

Hi Collin, > I prefer just changing this to an *.in.h file and replacing the variable > like you suggest. Could you double check the attached patch before I > push the change? The patch is technically correct, AFAICS. Except that I would prefer the file to be named fts.in.h instead of fts_.in.h.

Re: [PATCH] acl-tests: link with $(FILE_HAS_ACL_LIB)

dents qcopy-acl > >acl > >copy-file > >qacl > >supersede > > Thanks for this recipe; I'll try to remember it the next time Oh, if that's (even partially) not a well-known recipe, it's worth documenting. Done like this: 20

bison: Fix configure test failure if POSIXLY_CORRECT is set

Spotted on the #gnu IRC channel: checking for bison 2.4 or newer... 3.8.2, bad in an environment where POSIXLY_CORRECT is set. This patch should fix it. 2025-05-11 Bruno Haible bison: Fix configure test failure if POSIXLY_CORRECT is set. Reported by Arsen Arsenović

Re: fts: Fix redefinition of __THROW.

Hi Collin, > I prefer just changing this to an *.in.h file and replacing the variable > like you suggest. Could you double check the attached patch before I > push the change? Please hold off for the moment. The patch looks quite strange. Need to think through it all. Will do that tomorrow. Brun

Re: string-desc: Distinguish writable strings from read-only strings

4.9/changes.html>.) This patch fixes both problems. 2025-05-10 Bruno Haible string-desc: Fixes for string literals and older GCC versions. * lib/string-desc.h (HAVE__GENERIC, HAVE_BUILTIN_CHOOSE_EXPR, HAVE_BUILTIN_CONSTANT_P, HAVE_RW_STRING_DESC): New macros.

Re: fts: Fix redefinition of __THROW.

Hi Collin, > like in getopt-cdefs.in.h getopt-cdefs.in.h does this: #if @HAVE_SYS_CDEFS_H@ # include #endif It would be good to use the same idiom in fts_.h. The idea is that things are more robust if the value of some HAVE_* macro is taken directly from config.status, rather than from config.

Re: string-desc: Distinguish writable strings from read-only strings

> $ gcc --version | sed 1q > gcc (GCC) 15.1.1 20250425 (Red Hat 15.1.1-1) And the error is reproducible also with other compiler versions. gcc 13: In file included from ../../gllib/string-desc.c:20: ../config.h:1361:28: error: attributes should be specified before the declarator in a fu

Re: string-desc: Distinguish writable strings from read-only strings

rwards, but it seems like changing to > rw_string_desc_t where applicable will fix it. Yes. I just hadn't gotten around to pushing these changes. Bruno >From 66301a2e507024fbecfdba14a61eec1cfd2cb3c3 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 10 May 2025 15:06:47 +0200 Sub

Re: [PATCH] acl-tests: link with $(FILE_HAS_ACL_LIB)

s variable that needs to be updated. This automatically takes care of the dependents. 2025-05-10 Bruno Haible qcopy-acl: Update link dependencies after yesterday's change. * m4/acl.m4 (gl_QCOPY_ACL): Require gl_FILE_HAS_ACL. (QCOPY_ACL_LIB): Conditionally add $FILE_H

file-has-acl: Simplify logic for FILE_HAS_ACL_LIB

t is perfectly OK for gl_FILE_HAS_ACL to require gl_FUNC_ACL. This is even easier since gl_FUNC_ACL is defined through AC_DEFUN_ONCE (since 2023-01-13). Thus the upwards-propagation logic of gl_need_lib_has_acl can go away. 2025-05-10 Bruno Haible file-has-acl: Simplify logic f

string-desc: Detect invalid arguments to sd_substring

This patch improves the argument checking in sd_substring(). 2025-05-09 Bruno Haible string-desc: Detect invalid arguments to sd_substring. * lib/string-desc.c (sd_substring): Verify that the substring does not extend beyond the given string. diff --git a/lib/string

string-desc: Distinguish writable strings from read-only strings

match the parameter type. This patch fixes this problem, by distinguishing read-only strings and writable strings. Obviously, I did not want to duplicate the functions, e.g. sd_length to sd_length and rwsd_length. A single function should be applicable to both read-only string

HACKING: Update

An update, to consider the new warning options added in gcc 14,15 and clang 17 to 20. 2025-05-09 Bruno Haible HACKING: Update. * HACKING: Update for gcc 15 and clang 20. diff --git a/HACKING b/HACKING index e0f54a4ccf..eb1cd20031 100644 --- a/HACKING +++ b/HACKING @@ -182,11

Re: MSYS2 and mingw

Reuben Thomas wrote: > Also it would be nice to have some advice on what to use instead. Bruno > outlined to me that there are at least 3 options for developing for MinGW: > > 1. Cross-compile from GNU/Linux, use WINE to run compiled programs. > 2. Use MSYS2 (but we don't like this) > 3. Use Cygwi

Re: MSYS2 and mingw

Collin Funk wrote: > Since the whole MSYS2 thing has caused repeated confusion, including to > me [1], maybe we should add a section to the Gnulib manual. I agree with you that the best way to fix this confusion is through documentation. But not in the Gnulib manual, since the confusion is unrelat

Re: MSYS2 and mingw

Reuben Thomas wrote: > I am not using MSYS2 per se, I am using the Mingw64 environment There is no such thing as "the Mingw64 environment". Better be careful about the terms. We need to distinguish * mingw - which is a toolchain (set of runtime libraries, together with a customized

Re: relocatable failure on mingw owing to command-line argument processing by GCC

Hi Reuben, Reuben Thomas wrote: > ... > The problem appears to be that INSTALLDIR is passed to the compiler on the > command line, and something in the mingw64 machinery says "aha! it's a > path!" and transforms it to Windows style. Yes, this is the same problem for which I am writing in the INST

Re: strftime-induced linker errors on Android API 35.

th lookup rules like dcgettext("gnulib", ..., LC_TIME) would have. Generate this database from the glibc localedata sources. I went for approach B, because it is the simplest one. 2025-05-08 Bruno Haible nstrftime: Fix a link error on Android API level ≥ 35.

Re: [PATCH] Fix some ungrammatical uses of "allows to"

Paul Eggert wrote: > diff --git a/m4/libgcrypt.m4 b/m4/libgcrypt.m4 This change will be reverted by Karl's next autoupdate; see config/srclist.txt. Upstream libgcrypt.m4 is at https://dev.gnupg.org/source/libgcrypt.git . Bruno

Re: z/OS access

Hi Collin, > This reminds me. I recently found out IBM allows you to request access > to z/OS to "Develop and test open source on z/OS" or "Set up an open > source CI/CD pipeline on z/OS" [1]. There's also a similar option to request access to Linux/s390x hardware [4]. > I have no clue who uses

Re: [PATCH 1/2] obstack: check def before use in macros

Paul Eggert wrote: > > Does Solaris cc of > > version 0x5150 or newer really support statement-expressions? > > Yes it does[1]. Thanks for reporting the ChangeLog mistake; I installed > the attached. > > [1]: https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqexp Thanks!

Re: code formatting

Collin Funk wrote: > If we were to force code formatting conventions I would rather use > something comprehensive like clang-format. But I dislike that idea > anyways because unless every contributor uses the same version (very > unlikely), it leads to useless diff chunks due to formatter > disagre

Re: [PATCH 1/2] obstack: check def before use in macros

Paul Eggert wrote: > Simplify the logic for __extension__. > ... > @@ -329,9 +331,9 @@ extern int obstack_exit_failure; > > #define obstack_memory_used(h) _obstack_memory_used (h) > > -#if defined __GNUC__ || defined __clang__ > -# if ! (2 < __GNUC__ + (8 <= __GNUC_MINOR__) || defined __clang_

Add/fix some license notices

f the rows. 2025-05-07 Bruno Haible Add/fix some license notices. * lib/mcel.c: Use same license notice as lib/mcel.h. * lib/same-inode.c: Use same license notice as lib/same-inode.h. * lib/str_startswith.c: Change license notice to LGPLv2+. * lib/str_

Add syntax-check rule against misspelled predefs

To catch typos in predefined C macros, here are three patches. 2025-05-07 Bruno Haible Add syntax-check rule against CPU predef misspellings. * lib/getloadavg.c: Test __alpha, not __alpha__. * tests/test-snan-2.c: Likewise. * m4/exponentd.m4: Test __arm__, not

Remove obsolete syntax-check rules

top/maint.mk no longer has an explicit list of macros to check for, since 2016-12-30. Thus this rule is obsolete. 2025-05-07 Bruno Haible Remove obsolete syntax-check rules. * Makefile (sc_maint): Comment out. (sc_cpp_indent_check, sc_check_sym_list): Remove targets.

Fix "make sc_check_config_h_reminder" failure

/unistr.in.h lacks a config.h reminder. Needed for: _GL_ATTRIBUTE_DEALLOC_FREE _GL_ATTRIBUTE_MALLOC _GL_ATTRIBUTE_MAYBE_UNUSED File lib/unicase/special-casing.in.h lacks a config.h reminder. Needed for: _GL_ATTRIBUTE_NONSTRING Fixed as follows. 2025-05-07 Bruno Haible Fix "

Fix "make sc_prohibit_leading_TABs" failures

Some of the existing syntax-check rules have apparently not been exercised in a long time. This patch fixes one of them. 2025-05-07 Bruno Haible Fix "make sc_prohibit_leading_TABs" failures. * Makefile (exclude_file_name_regexp--sc_prohibit_leading_TABs): New

Tidy "make sc_prohibit_AC_LIBOBJ_in_m4" check

This patch refactors one of the syntax-check rules. 2025-05-07 Bruno Haible Tidy "make sc_prohibit_AC_LIBOBJ_in_m4" check. * Makefile (sc_prohibit_AC_LIBOBJ_in_m4): Don't hide the rule commands. (allow_AC_LIBOBJ): Remove exceptions that are no longe

Fix "make sc_prohibit_sc_omitted_at" failure

It's better to show the Makefile commands being executed, than to hide them. Transparency rules. 2025-05-07 Bruno Haible Fix "make sc_prohibit_sc_omitted_at" failure. * Makefile (sc_prohibit_sc_omitted_at): Don't apply to this Makefile. (sc_*):

Fix "make sc_prefer_ac_check_funcs_once" failure

2025-05-07 Bruno Haible Fix "make sc_prefer_ac_check_funcs_once" failure. * Makefile (exclude_file_name_regexp--sc_prefer_ac_check_funcs_once): New variable. (sc_prefer_ac_check_funcs_once): Use it. diff --git a/Makefile b/Makefile index 5fcc02510a..

Re: stddef-h: Fix __GNUC_MINOR__ typo.

Collin Funk wrote: > This patch fixes the uses of __GNUC_MINOR which should instead be > __GNUC_MINOR__: We had similar mistakes with __clang_major__ already. Sounds like a general syntax-check rule would help. Bruno

Re: [PATCH 12/19] obstack: _obstack_free → __obstack_free

Paul Eggert wrote: > As I'm still a bit concerned that glibc reviewers will object to > removing the "ifndef __obstack_free" I installed the attached further > patch. Looks good to me. But the CIs will tell whether it really works fine. > This further patch affects only people not using Gnulib

  1   2   3   4   5   6   7   8   9   10   >