Bruno Haible writes:
> 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 follow the naming scheme *.in.h of other header files in gnulib,
> - packages like coreutils and findutils are not broken.
In a testdir of all of gnulib, built with
GCC 15 and CFLAGS="-O2 -g -Wsystem-headers" CXXFLAGS="-O2 -g -Wsystem-headers",
I see the following -Wsystem-headers warnings:
../gllib/string.h:754:20: warning: declaration of 'void* memcpy(void*, const
void*, size_t)' has a different exception specifier
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 redundant 'return
In libunistring, I see these -Wunterminated-string-initialization warnings:
uninorm/composition-table.gperf:100:8: warning: initializer-string for array of
'char' truncates NUL terminator but destination lacks 'nonstring' attribute (7
chars into 6 available)
uninorm/composition-table.gperf:101:8
On Sun, May 11, 2025 at 3:38 PM Bruno Haible 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.
Fine with me.
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
Hi Bruno,
Bruno Haible writes:
> The patch is technically correct, AFAICS. Except that I would prefer the
> file to be named fts.in.h instead of fts_.in.h.
>
> We have a common naming idiom that the include file names should be the
> same as the customary ones in Unix. So that applications don't
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.
Paul Eggert wrote:
> > Here, after the qcopy-acl change yesterday, the following modules need
> > to link with $(FILE_HAS_ACL_LIB), at least conditionally:
> >* qcopy-acl
> >* The dependents of qcopy-acl:
> >$ ./gnulib-tool --extract-dependents qcopy-acl
> >acl
> >co
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ć.
Collin Funk writes:
> This patch broke Coreutils on some systems due to not defining
> __GNU_PREREQ [1].
Forgot to attach the pushed patch
Collin
>From a92aa179978a136fa9cc9023d02b5529b19a2210 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sun, 11 May 2025 09:41:48 -0700
Subject: [PATCH] ft
Collin Funk writes:
> I have pushed the attached patch which fixes that and defines the macros
> correctly like in getopt-cdefs.in.h as opposed to just undefining them.
This patch broke Coreutils on some systems due to not defining
__GNU_PREREQ [1].
I could not produce it on the Alpine cfarm sy
12 matches
Mail list logo
