On 4/30/25 18:33, Collin Funk wrote:
(I would not bet that code like this:
#if 0
# if @FOOBAR@
# endif
#endif
works for all C and C++ compilers. Better avoid that.)
I always wondered if a compiler would fail with that.
The C standard has required it to work ever since C89 (see its
Hi Bruno,
Bruno Haible writes:
> modules/ieee754-h is simpler, with a use of _GL_GNULIB_HEADER that is
> effectively replaced with 1 on the gnulib side. But this works only if
> there are no other substitutions to be made (no @...@ replacements)
> in preprocessor lines. (I would not bet that cod
On 2025-04-28 02:43, Bruno Haible wrote:
Paul Eggert wrote:
Remove -Wdisabled-optimization, as this is a warning about the
compiler not the program.
Does gcc's warning message give a hint how the compiler options could
be adjusted, so as to enable the optimization?
Unfortunately not, at leas
References:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/types.h
---
doc/gnulib-readme.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index 3d2d09fefb..aa1b1524a2 100644
--- a/doc/gnulib-readme.texi
+
Hi Pádraig,
> FYI I see these failures in coreutils CI with latest gnulib.
There were two mistakes, indeed.
> src/copy.c: In function 'dest_info_init':
> src/copy.c:2026:24: error: 'triple_hash' undeclared (first use in this
> function)
> 2026 |triple_hash,
>|
Yesterday I did:
> Rename module hash-pjw to hashcode-string.
It's not that easy: We have 3 different implementations of hash codes
for strings:
(1) glibc/intl/hash-string.[hc] = gettext-runtime/intl/hash-string.[hc]
(2) inside lib/hash.c
(3) in lib/hashcode-string.[hc].
I don't want
On 29/04/2025 23:57, Bruno Haible via Gnulib discussion list wrote:
The naming of *hash* modules is suboptimal: On one hand, we have the
hash tables and containers:
hash, hash-map, hash-set, linkedhash-map, linkedhash-set,
avltreehash-list, linkedhash-list, rbtreehash-list,
on the other han
Hi Collin,
> > That glibc patch needs more work, as I think Gnulib is misusing _LIBC.
> > _LIBC means we're using the header while compiling glibc itself,
> > whereas obstack.h appears in /usr/include/obstack.h and is used in
> > other contexts.
>
> I see.
>
> In lib/cdefs.h there is '#ifndef __
