Re: commit signing

On Sun, Jul 20, 2025 at 4:19 PM Bruno Haible wrote: > > 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 m

Re: [musl] Re: alx-0029r3 - Restore the traditional realloc(3) specification

On Tue, Jun 24, 2025 at 10:18 AM Alejandro Colomar wrote: > > Hi Florian, > > On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote: > > [...] > > Wouldn't it be more consistent to move in the other direction, and > > require that allocations of zero size fail because C does not support >

Re: a country name change

On Tue, Jun 3, 2025 at 7:19 PM Collin Funk wrote: > > Bruno Haible writes: > > >> $ grep -rie 'yugoslav' > >> lib/setlocale_null.h: ("FYRO Macedonian_Former Yugoslav Republic of > >> Macedonia.1251"). */ > >> lib/setlocale.c: MKI FYRO Macedonian_Former Yugoslav Republic of >

Re: _Countof operator and countof macro (C2y)

On Mon, Jun 2, 2025 at 7:29 AM Bruno Haible via Gnulib discussion list wrote: > > Hi Alejandro, > > > I've added the _Countof to ISO C2y and GCC 16. Clang 21 has also added > > it. There's a compiler header with a countof macro too. > >

Re: Rust build system

On Fri, Apr 25, 2025 at 7:28 AM Bruno Haible wrote: > > Jeffrey Walton wrote: > > Also see Rust's Platform Support, > > <https://doc.rust-lang.org/beta/rustc/platform-support.html>. Tier 1 > > is expected to build and run correctly. Tier 1 is i686, x86_64 an

Re: Rust build system

On Fri, Apr 25, 2025 at 6:34 AM Bruno Haible via Gnulib discussion list wrote: > > Nikolaos Chatzikonstantinou wrote: > > > One problem I see with Rust is that currently it does not integrate well > > > with the GNU Build system, in particular with VPATH builds (see [3] for > > > an example integr

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

On Thu, Apr 17, 2025 at 2:33 AM Simon Josefsson via Gnulib discussion list wrote: > > I got a CI/CD build failure [1] for libidn on the new release fedora 42. > > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: creating csharpco

Re: vma-iter: Detect executable memory segments on Haiku (regr. 2011-01-25).

On Thu, Mar 13, 2025 at 10:23 PM Collin Funk wrote: > > On Haiku, test-vma-prot fails with the following: > > ../../gltests/test-vma-prot.c:68: assertion 'prot == (VMA_PROT_READ | > VMA_PROT_WRITE)' failed > Abort > FAIL test-vma-prot (exit status: 149) > > At this point, the followin

Re: announce-gen project link and mirrors

On Thu, Feb 6, 2025 at 9:59 PM Jim Meyering wrote: > > On Thu, Feb 6, 2025 at 3:06 PM Simon Josefsson via Gnulib discussion > list wrote: > > Announce-gen generate this snippet: > > > > > Here is the GNU libtasn1 home page: > > > https://gnu.org/s/libtasn1/ > > > > Why? Shouldn't we use the

Re: crc-x86_64: undefined behaviour

On Fri, Jan 17, 2025 at 1:05 PM Paul Eggert wrote: > > On 2025-01-17 06:44, Jeffrey Walton wrote: > > Change: > > > > const __m128i *data = buf; > > > > To this so the compiler cannot pick between MOVDQA and MOVDQU: > > > > const __m12

Re: crc-x86_64: undefined behaviour

ces here? Jeff > On Fri, 17 Jan 2025 at 08:11, Paul Eggert wrote: >> >> On 2025-01-16 21:25, Jeffrey Walton wrote: >> > On Fri, Jan 17, 2025 at 12:07 AM Bruno Haible via Gnulib discussion >> > list wrote: >> >> Yes, the undefined behaviour really starts h

Re: crc-x86_64: undefined behaviour

On Fri, Jan 17, 2025 at 12:07 AM Bruno Haible via Gnulib discussion list wrote: > > Paul Eggert wrote: > > > ../lib/crc-x86_64-pclmul.c:120:26: runtime error: load of misaligned > > > address 0x5572a8d5f161 for type 'const __m128i *', which requires 16 byte > > > alignment > > > 0x5572a8d5f161:

Re: base64: gcc-15 compile issue

On Sat, Dec 21, 2024 at 9:45 AM Bruno Haible via Gnulib discussion list wrote: > > Rudi Heitbaum wrote: > > When compiling grub-2.12 with gcc-15-20241208 the following line causes > > the following error: > > > > https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/base64.c#n62 > > > > ../../grub

Re: OpenPGP keys

On Wed, Dec 11, 2024 at 1:16 PM Bruno Haible via Gnulib discussion list wrote: > > [...] > > if I got your PGP > > key a couple of years ago and still have it locally, your newly made > > signature will verify against it. I wouldn't fetch your key on every > > verification attempt. It is only wh

Re: signbit(), C++, and Solaris 10

On Fri, Dec 6, 2024 at 1:41 PM G. Branden Robinson wrote: > > [...] > I run it with "bash ../go" to avoid Solaris 10 /bin/sh, the World's > Worst Shell. Solaris is an acquired taste :) You can probably find non-anemic tools at /usr/gnu/bin or /usr/sfw/bin. Jeff

Re: signbit(), C++, and Solaris 10

On Fri, Dec 6, 2024 at 1:16 PM G. Branden Robinson wrote: > > At 2024-12-06T16:49:13+, Colin Watson wrote: > > On Fri, Dec 06, 2024 at 06:04:57AM -0600, G. Branden Robinson wrote: > > > Is there something I can specify to "configure" or make(1) to > > > override gnulib's decision here? > > > >

Re: announce-gen: Show an SHA256 sum that can be verified more easily

On Sun, Dec 1, 2024 at 9:04 AM Simon Josefsson via Gnulib discussion list wrote: > > Bruno Haible via Gnulib discussion list writes: > > > The 'announce-gen' script shows SHA256 sums in a way that are hard to verify > > and understand for the users: > > - Verifying requires a special command th

Re: [PATCH] crc: Add PCLMUL implementation

On Tue, Nov 26, 2024 at 4:27 PM Sam Russell wrote: > > I've added an alignment check in lib/crc, it looks like the code works okay > without it for me but an _m128 is supposed to be 128-bit aligned so I'm happy > that I've added it. The _m128i's are naturally aligned. They will be ok: +

Re: [PATCH] crc: New optimised slice-by-8 implementation

On Thu, Oct 31, 2024 at 5:15 PM Simon Josefsson via Gnulib discussion list wrote: > > Pádraig Brady writes: > > > I'd be reluctant to complicate the gnulib implementations with variants > > unless needed. > > I'd be especially reluctant to add the existing cksum crc variant to gnulib, > > since

Re: [PATCH 2/2] posix_memalign: check for GNU behavior with size 0

On Wed, Oct 30, 2024 at 3:51 PM Paul Eggert wrote: > > * lib/posix_memalign.c: Include stdckdint.h. > (posix_memalign): Test for overflow more straightforwardly, > and more portably to unlikely platforms where SIZE_MAX <= INT_MAX. > Treat a zero size as if it were alignment. > * m4/posix_memalign.

Re: Adding slice-by-4 and slice-by-8 to CRC32

On Tue, Oct 15, 2024 at 10:59 AM Pádraig Brady wrote: > > On 15/10/2024 12:58, Sam Russell wrote: > > I'm happy with the slice-by-8 code I have > > > > but the > > c

Re: Adding slice-by-4 and slice-by-8 to CRC32

On Mon, Oct 14, 2024 at 5:11 PM Sam Russell wrote: > > One issue I've noticed is that the crc functions take a char* and while this > is ok in other implementations, gnulib appears to enforce strict alignment > (presumably for portability purposes). > > Because of this, we might need to introduc

Re: Adding slice-by-4 and slice-by-8 to CRC32

On Mon, Oct 14, 2024 at 2:26 PM Simon Josefsson via Gnulib discussion list wrote: > > Sam Russell writes: > > > I've noticed that GZIP trails behind zlib in performance and part of this > > is down to the fact that zlib is using a more efficient CRC32 > > implementation. I've written an implement

Re: string-desc: Fix undefined behaviour

On Mon, Sep 9, 2024 at 8:08 PM Bruno Haible wrote: > > Running some gnulib tests with clang's UBSAN, I get this error in the file > test-string-desc.sh.log: > > string-desc-contains.c:39:13: runtime error: null pointer passed as > argument 1, which is declared to never be null > /usr/include/

Re: striconv, striconveh, unicodeio: Drop workaround for glibc 2.1

On Mon, Sep 9, 2024 at 4:04 PM Paul Eggert wrote: > > On 2024-09-09 07:06, Bruno Haible wrote: > > And more of the same kind. Solaris 9's successor, Solaris 10, was released > > in 2005. Solaris 9 workarounds therefore can also be dropped. > > Yes, sounds good. The rule I suggest is that if a dist

Re: savewd: please port to native Windows

On Tue, Aug 27, 2024 at 5:25 PM Paul Eggert wrote: > > On 2024-08-27 13:34, Bruno Haible wrote: > > > gllib\savewd.c(73,27): warning: implicit declaration of function 'fork' is > > invalid in C99 [-Wimplicit-function-declaration] > > Perhaps the attached patch? Re: +# if O_SEARCH != O_RDONLY ||

Re: a world without as

On Tue, Aug 20, 2024 at 11:09 AM Bruno Haible wrote: > > A note regarding portability: > > The assembler, 'as', is no longer a required program on developer machines. > > FreeBSD 14.0 ships with clang as default compiler, and clang has an > embedded assembler. Yes, one can install the 'binutils' p

Re: should asprintf and friends guarantee sane pointer on failure?

On Mon, Jul 29, 2024 at 11:37 AM Bruno Haible wrote: > > Jeffrey Walton wrote: > > You should consider making the interface easy to use correctly, and > > hard to use incorrectly. That will help novice programmers avoid > > mistakes. > > Novice programmers need to l

Re: should asprintf and friends guarantee sane pointer on failure?

On Mon, Jul 29, 2024 at 10:36 AM Bruno Haible wrote: > > I see two — mostly unrelated — topics in your mail and the referenced > threads. > > 1) The coding paradigm. > >30 years ago I saw a piece of code from Microsoft, which called >fopen() and assumed that the return value was != NULL. >

Need for -std=gnu89 or -std=c99 on MacOS

Hi Everyone, In case you are not following the thread, part of GnuPG may need -std=gnu89 on MacOS. It looks like -std=c99 may also be a workaround. See the original post[1] and the proposed workaround [2]. [1] [2]

Re: We can not run gnulib-tool in the MinGW.

On Sat, Jul 6, 2024 at 12:40 PM Bruno Haible wrote: > > Paul Eggert wrote: > > > are we OK to drop the ability to run gnulib-tool on Solaris 10? > > > > I'm OK with it. When I deal with Solaris 10 (hey, our department's admin > > server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and c

Re: Integer overflows in memchr

On Tue, Jul 9, 2024 at 7:56 PM Paul Eggert wrote: > > On 7/9/24 22:03, Eric Blake wrote: > > https://www.austingroupbugs.net/view.php?id=1834#c6830 > > > > The current draft of proposed wording would have the C standard state: > > > > 2 The strnlen function counts not more than n characters (a nul

Re: We can not run gnulib-tool in the MinGW.

On Wed, Jul 3, 2024 at 11:27 PM anlex N wrote: > > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > $ ./gnulib-tool --list > > I run this command in the gnulib source code, but have no output, why? In the past, I had problems compiling Rufus on MinGW, even though Rufus specifically said to

Re: continuous integration for many platforms

On Thu, Jun 6, 2024 at 5:34 PM Bruno Haible wrote: > > The continuous integration of Gnulib for many platforms is now operational. > Congrats. That is a great accomplishment. Jeff

Re: call_once: Work around Cygwin 3.5.3 bug

On Thu, May 30, 2024 at 5:38 AM Bruno Haible wrote: > > call_once, being implemented on top of pthread_once in Cygwin, is affected > by the same bug, and needs a workaround as well. Be careful of call_once. Be sure to test it on non-x86 machines. See bugs like

Re: byteswap side-effect defect report from Coverity

On Mon, May 20, 2024 at 5:43 PM Bruno Haible wrote: > Jeffrey Walton wrote: > > I think this is a valid finding. It will operate one way in release > builds > > (-DNDEBUG), and another way in debug builds (no NDEBUG). > > No. Like Coverity, you are assuming that &#x

Re: byteswap side-effect defect report from Coverity

On Mon, May 20, 2024 at 12:13 PM Paul Eggert wrote: > Bruno and I get defect reports from Coverity Scan for Gnulib. The most > recent one has this new complaint: > > > *** CID 1588680: Incorrect expression (ASSERT_SIDE_EFFECT) > > /gltests/test-byteswap.c: 43 in test_bswap_eval_once() > > 37 >

Re: byteswap.h behavior

On Sun, May 12, 2024 at 3:23 PM Collin Funk wrote: > A few months ago there was a suggestion on emacs-devel to use > __builtin_bswap functions when available [1]. While I agree that GCC > can deal with the optimizations properly, I noted an important > difference between the macros in byteswap.h.

Re: OSError: [WinError 193] %1 is not a valid Win32 application

On Wed, May 1, 2024 at 10:11 AM Bruno Haible wrote: > Hi Jeffrey, > > We don't need to discuss how "make install" in Autoconf and Automake should > work. Let's keep focused on the current question: how to invoke the > Autoconf and Automake programs, assuming they already exist on the user's > dis

Re: OSError: [WinError 193] %1 is not a valid Win32 application

On Wed, May 1, 2024 at 6:51 AM Bruno Haible wrote: > [...] > > I assume that windows doesn't do anything about the '#!/bin/sh' line. > > Indeed, that is likely the explanation: All 3 programs (autoconf, > autoheader, automake) start with '#!/usr/bin/perl', and while native > Windows does not inte

Re: signed-nan: Don't assume that '-' works as expected on NaN values

On Fri, Apr 19, 2024 at 8:06 AM Bruno Haible wrote: > ... > > +/* Returns - x, implemented by inverting the sign bit, > + so that it works also on 'float' NaN values. */ > +_GL_UNUSED static float > +minus_NaNf (float x) > +{ > +#if defined __mips__ > + /* The mips instruction neg.s may have

Re: autoreconf --force seemingly does not forcibly update everything

On Wed, Apr 10, 2024 at 5:44 PM Paul Eggert wrote: > > On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: > > Is bootstrap intended to be reliable from within a tarball? I thought > > the bootstrap script was not included in tarballs because it wasn't > > designed to be ran that

Re: autoreconf --force seemingly does not forcibly update everything

On Mon, Apr 1, 2024 at 2:31 PM Bruno Haible wrote: > > Thanks for the forward, Eric. > > Guillem Jover wrote in > : > > > Hi! > > > > > > While analyzing the recent xz backdoor hook into the build system [A], > > > I noticed th

Re: lib/malloca.c, different signs of integers; with clang and groff

On Mon, Feb 5, 2024 at 2:59 PM Bruno Haible wrote: > > Bjarni Ingi Gislason wrote: > > $(lib_libgnu_a_CFLAGS) is put before $(CFLAGS). > > This is as it should be. The user-provided CFLAGS must override the > package-provided lib_libgnu_a_CFLAGS. Rationale: "The user is always right". ++. See

Re: test-argp and clang's ASAN

On Sun, Dec 3, 2023 at 7: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: undefined-behavior obstack.c:139

On Fri, Dec 1, 2023 at 8:15 AM Bruno Haible wrote: > > [CCing bug-gnulib because obstack.c comes from gnulib.] > > Alexey Palienko wrote in > : > > > It has been built by clang 13 with "-g -fsanitize=address,undefined > > -fno-omit

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

On Tue, Nov 14, 2023 at 5:13 AM John Paul Adrian Glaubitz wrote: > > Hi Jeffrey! > > On Tue, 2023-11-14 at 00:50 -0500, Jeffrey Walton wrote: > > On SPARC, 64-bit words can be loaded and saved through one of two > > instructions. The first version is optimized, the second

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

On Tue, Nov 14, 2023 at 12:50 AM Jeffrey Walton wrote: > > On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote: > > > > Sam James wrote: > > > It appears that the obstack gnulib module is the culprit. > > > > When I compile texinfo-7.1 in such a way tha

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote: > > Sam James wrote: > > It appears that the obstack gnulib module is the culprit. > > When I compile texinfo-7.1 in such a way that is uses the obstack facility > from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same > bus

Re: doc: Mention rand and srand limitations

Hi Bruno, On Fri, Nov 10, 2023 at 2:03 PM Bruno Haible wrote:> > rand() is not required to be multithread-safe. So, it's not a bug when rand() > is not MT-safe on some platforms; it's merely a portability problem worth > documenting. > > The attached program tests the MT-safety. Results: OK on al

Re: Test failures on legacy Darwin/powerpc

On Thu, Nov 9, 2023 at 1:00 PM Sevan Janiyan wrote: > > On 10.4 > FAIL: test-nanosleep > > > test-nanosleep.c:50: assertion 'nanosleep (&ts, NULL) == -1' failed > FAIL test-nanosleep (exit status: 134) > > > On 10.4 & 10.5 > FAIL: test-float > > > test-float.c

Clang, MSYS2 and MSVC

Hi All, A quick heads up... We caught a bug report because Clang got into a code path intended for MSVC. The problem is like the Apple and LLVM CLang problem. The issue surfaced recently for us on WIndows platforms. We expected Clang to get into certain code paths for MSYS2 (and MinGW and Cygwin)

Re: Including config.h emits warnings from -Wundef

On Thu, Aug 3, 2023 at 11:52 AM Tim Rühsen wrote: > > I just updated gnulib and recognized these warnings with every '#include > '. Before the update there were no warnings. > > ../config.h:3317:34: warning: "__cplusplus" is not defined, evaluates to > 0 [-Wundef] > [...] > Disabling -Wundef for t

Re: manywarnings: Overhaul documentation

On Mon, Jun 5, 2023 at 4:26 PM Paul Eggert wrote: > > On 2023-06-04 15:18, Bruno Haible wrote: > > > +Do this once with optimizations (@code{CPPFLAGS=-O2}) and once with no > > +optimizations (@code{CPPFLAGS=-O0} or @code{CPPFLAGS=-ggdb}). > > -ggdb shouldn't affect warnings, no? > > More generall

Re: fopen: Silence a gcc warning

On Tue, May 2, 2023 at 2:56 PM Bruno Haible wrote: > > The continuous integration of 'gzip' failed today: > > CC fopen.o > fopen.c: In function 'rpl_fopen': > fopen.c:50:7: error: variable 'open_direction' set but not used > [-Werror=unused-but-set-variable] >50 | int open_direction

Re: ISO C 23, , and once_flag

On Sat, Mar 25, 2023 at 5:05 PM Bruno Haible wrote: > > In ISO C 23, > - the type 'once_flag', > - the macro ONCE_FLAG_INIT, > - the declaration of function 'call_once' > are all available from , not only from . > > 1) This makes it clear that often call_once is needed in an application > wi

Re: RFC: add a string-desc module

On Fri, Mar 24, 2023 at 5:50 PM Bruno Haible wrote: > > In most application areas, it is not a problem if strings cannot contain NUL > bytes, and thus the C type 'char *' with its NUL terminator is well usable. > > In areas where strings with embedded NUL bytes need to be handled, the common > app

Re: Apple LLVM 10 and `__fallthrough__`

On Sun, Feb 26, 2023 at 10:08 PM Alexei Podtelezhnikov wrote: > > On Sun, Feb 26, 2023 at 7:08 PM Bruno Haible wrote: > > > > Alexei Podtelezhnikov wrote: > > > -# elif (__GNUC__ >= 7) || (__clang_major__ >= 10) > > > +# elif ((__GNUC__ >= 7) \ > > > +|| (defined __apple_build_version__ \

Re: Apple LLVM 10 and `__fallthrough__`

On Sun, Feb 26, 2023 at 6:36 PM Alexei Podtelezhnikov wrote: > [...] > Would it perhaps be better if clang used [[fallthrough]] instead of > __attribute__((fallthrough))? They have supported [[fallthrough]] > since at least 3.5.0 circa 2014. In this particular case they are > ahead of GCC and to

Re: nullptr in C++ mode on macOS

On Thu, Feb 9, 2023 at 2:31 PM Bruno Haible wrote: > > On macOS 12.5 (machine: gcc104.fsffrance.org), the test-nullptr-c++.cc fails > to compile: One of the sharp edges you may be encountering is, LLVM was shipping a C++03 compiler by default. You had to do something special to use C++11 (-std=c+

Re: groff with "nullptr" and (without) gnulib module causes error

On Wed, Feb 8, 2023 at 2:24 PM Bjarni Ingi Gislason wrote: > [...] > Build with gnulib nullptr module or without it causes > > CXX src/roff/troff/input.o > ../src/roff/troff/input.cpp: In member function 'void token::next()': > ../src/roff/troff/input.cpp:2078:18: error: invalid operands

Re: Gnulib and nullptr

On Sun, Feb 5, 2023 at 9:45 PM Paul Eggert wrote: > > On 2023-02-05 18:00, Bruno Haible wrote: > > Why call it 'c-nullptr', not 'nullptr'? > > I was worried about C++, not that I know much about it, and operated by > analogy with the name of m4/c-bool.m4. If 'nullptr' is a better name > then let's

Re: Android environments

On Tue, Dec 27, 2022 at 3:05 AM Po Lu wrote: > > Bruno Haible writes: > > > I see. There are two ways to build C programs for Android: > > > > (A) The way it is designed by Google: With the Android NDK, > > that includes a cross-compiler. For the runtime, use an emulator > > (based

Re: -Wlto-type-mismatch warning in error()

On Thu, Dec 8, 2022 at 3:58 AM Arsen Arsenović via Gnulib discussion list wrote: > > Eli Zaretskii writes: > > >> Whereas with the Gnulib 'error' module, there is a conflict between the > >> two global function definitions (with 'T' linkage) in install-info.c and > >> in error.c *always*. > >> >

Re: [PATCH][gnulib] Add the Sframe package

On Thu, Nov 17, 2022 at 8:24 PM Bruno Haible wrote: > > Weimin Pan wrote: > > We came to design the SFrame format (The S stands for `simple') due to some > > concrete requirements of a very big program that ships its own "online" > > stack tracer and unwinder to handle error conditions: > > > > 1)

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Wed, Nov 16, 2022 at 1:18 PM Paul Eggert wrote: > ... > If Clang's threatened pickiness were of some real use elsewhere, it > might be justifiable for default Clang to break Autoconf. But so far we > haven't seen real-world uses that would justify this pickiness for > Autoconf's use of 'char me

Re: best way to deal with macOS deprecation of sprintf?

On Thu, Nov 3, 2022 at 3:23 PM Paul Eggert wrote: > > As noted in , macOS 13.0 has deprecated > sprintf, on the grounds that buffer overflow happens too often with it. > As a result, compilers will complain about any calls to sprintf, even if > you don't configure with

Re: assert-h: Make static_assert work on Solaris 11.4

On Tue, Oct 25, 2022 at 2:13 PM Paul Eggert wrote: > > On 2022-10-23 07:47, Bruno Haible wrote: > >#include > >#undef/**/assert > > + /* Solaris 11.4 defines static_assert as a macro with 2 > > arguments. > > +We need it also to be invocable with a single argument. */ > > + #if def

Re: getdelim: Work around buggy implementation on macOS 10.13

On Sun, Oct 23, 2022 at 11:57 PM Simon Josefsson via Gnulib discussion list wrote: > > Bruno Haible writes: > > > While testing a GNU sed snapshot on macOS 10.13, I see this test failure: > ... > > ==85029== Invalid read of size 16 > ... > > An out-of-bounds read. Oh oh. When I reconfigure and re

Re: [PATCH 1/1] regex: fix broken clang build

On Tue, Jun 14, 2022 at 9:25 AM Darren Kenny wrote: > > The use of variable-length arrays (VLAs) is disabled by default in > clang 9 and above. > > The same pragma that works for GCC also works for clang, so check for > clang 9+ too. > > Signed-off-by: Darren Kenny > --- > lib/regex.h | 6 --

Re: Parallelization of shell scripts for 'configure' etc.

On Tue, Jun 14, 2022 at 11:15 PM Ángel wrote: > > On 2022-06-13 at 18:32 -0700, Paul Eggert wrote: > > Yes, all that could be done in theory, but it'd take a lot of > > hacking and it's been decades and it hasn't happened. > > > > I'd rather have shell scripts "just work" in parallel with a minimu

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

On Fri, Jun 3, 2022 at 9:54 PM Paul Eggert wrote: > > While testing, I discovered that master-branch grep's bootstrap script > contained a regular expression with '\]' that master-branch grep now > warns about. I fixed this portability bug in 'bootstrap' by installing > the following patch into Gn

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

On Sun, Apr 17, 2022 at 10:33 AM Ryan Schmidt wrote: > > On Apr 17, 2022, at 02:54, Paul Eggert wrote: > > > On 4/16/22 20:28, Jeffrey Walton wrote: > >> maybe you should define a couple of macros > >> like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER > &

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

On Sat, Apr 16, 2022 at 10:21 PM Paul Eggert wrote: > > On 4/15/22 09:22, Mattias Engdegård wrote: > > Paul, would you consider something like that patch (repeated here) for > > gnulib? > > Sure, I installed the attached into Gnulib master on Savannah. > > I suppose it wouldn't hurt for an old Ma

Re: Issue building gnulib with clang (as used in GRUB)

On Fri, Mar 25, 2022 at 10:00 AM Paul Eggert wrote: > > ... > > he possible > > security issue is that this size variable can be manipulated > > to enable mis-use via a stack overflow > That issue shouldn't happen here; i.e., the diagnostic is a false alarm. I believe the security issue is simila

Re: Ncurses support?

On Fri, Feb 25, 2022 at 2:26 PM Mike Frysinger wrote: > > On 25 Feb 2022 04:31, Jeffrey Walton wrote: > > On Fri, Feb 25, 2022 at 3:58 AM Mike Frysinger wrote: > > > On 25 Feb 2022 02:45, Jeffrey Walton wrote: > > > > On Fri, Feb 25, 2022 at 1:53 AM Mike Frysinge

Re: Ncurses support?

On Fri, Feb 25, 2022 at 3:58 AM Mike Frysinger wrote: > > On 25 Feb 2022 02:45, Jeffrey Walton wrote: > > On Fri, Feb 25, 2022 at 1:53 AM Mike Frysinger wrote: > > > On 25 Feb 2022 00:42, Jeffrey Walton wrote: > > > > On Thu, Feb 24, 2022 at 6:07 PM Bruno Haible w

Re: Ncurses support?

On Fri, Feb 25, 2022 at 1:53 AM Mike Frysinger wrote: > > On 25 Feb 2022 00:42, Jeffrey Walton wrote: > > On Thu, Feb 24, 2022 at 6:07 PM Bruno Haible wrote: > > > Have you reported it? > > > https://invisible-island.net/ncurses/ncurses.faq.html#report_bugs >

Re: Ncurses support?

On Thu, Feb 24, 2022 at 6:07 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > > What trouble do you get? Portability problems? > > > > Fails to build on some platforms. Solaris is the latest casualty. > > ... > > 3. Runtime execution. Leaks memory li

Re: Ncurses support?

> > My goal is to find a way to drop Ncurses from my build scripts. It > > causes too much trouble. > > What trouble do you get? Portability problems? Fails to build on some platforms. Solaris is the latest casualty. > > The rub is, a lot of programs depend on it. > > What do these programs actua

Ncurses support?

Hi Everyone, I saw Gnulib started carrying some terminal info support. My goal is to find a way to drop Ncurses from my build scripts. It causes too much trouble. The rub is, a lot of programs depend on it. Is it possible to provide a Ncurses replacement via Gnulib? Is this something the project

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Thu, Jan 20, 2022 at 8:24 AM Ryan Schmidt wrote: > > > On Jan 18, 2022, at 15:18, Reuben Thomas wrote: > > > > On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote: > >> > >> If you are OS X 10.8 and above, then you will likely be using Apple > >

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, Jan 18, 2022 at 2:54 PM Reuben Thomas wrote: > > On Tue, 18 Jan 2022 at 18:38, Paul Eggert wrote: > > > > I'm not sure a newer compiler would fix the bugs, as they're typically > > present in the ctype.h supplied by the OS. If the newer compiler comes > > with a fixed ctype.h you're OK; i

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, Jan 17, 2022 at 5:14 PM Paul Eggert wrote: > > On 1/17/22 10:37, Reuben Thomas wrote: > > > "extern-inline" copies a stanza of code into > > config.h. That code includes a test of the preprocessor macro > > "__header_inline". That macro is defined in a system header on macOS. > > When conf

Re: [bug-diffutils] bug#53256: Compiling 3.8 with nvhpc 22.1 : malloca.c 64 bits operations with signed and unsigned operands are currently unsupported by __builtin_add_overflow

On Fri, Jan 14, 2022 at 10:53 PM Paul Eggert wrote: > ... > Thanks for the bug report. Although nvc 22.1 defines __GNUC__ to be 11 > which means it supports GNU C as of GCC 11, that's obviously untrue for > __builtin_add_overflow. That's unfortunate. Perhaps you could report > this as a bug to NVI

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

On Mon, Nov 1, 2021 at 4:02 PM Paul Eggert wrote: > > On 10/21/21 12:38, Paweł Krawczyk wrote: > > > gl_array_list.c:452:29: runtime error: applying zero offset to null pointer > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior > > gl_array_list.c:452:29 in > > The Gnulib portability ass

Re: bug#51144: GNU grep 3.7 fails to build on FreeBSD

On Sat, Oct 16, 2021 at 12:53 PM Paul Eggert wrote: > > On 10/16/21 9:40 AM, Tijl Coosemans wrote: > > Where > > necessary we simply pass --build=x64_64-portbld-freebsd$(version). An > > example is gcc. > > Could you pass --build=x64_64-portbld-freebsd$(version) to every > 'configure' invocation,

Re: gendering

On Sat, Sep 18, 2021 at 9:19 PM Bruno Haible wrote: > > This gendering stuff is generally off-topic on this list, but it came up here, > therefore I'm replying here. I hope the thread will be short, since so much > has already been written on this topic. > > Hi Colin, > > You wrote: > > CCing Brun

Re: Problem with add_exclude_file()

On Mon, May 24, 2021 at 7:39 AM Gisle Vanem wrote: > ... > So I patched 'exclude.c' like this: > --- a/lib/exclude.c 2021-03-17 21:03:14 > +++ b/lib/exclude.c 2021-05-24 13:33:05 > @@ -683,7 +683,7 @@ > > if (use_stdin) > in = stdin; > - else if (! (in = fopen (file_name, "re"))) > + e

Re: malloc/dynarray-skeleton.c problems on MacOS 10.13.6 and 10.15.7

On Fri, May 7, 2021 at 2:13 AM wrote: > > Hi Paul & Jim, > > Please see the report below from Nelson Beebe, attempting to build > https://www.skeeve.com/gawk/gawk-5.1.1a.tar.gz on recent MacOS. > This a test release, working towards a real release. > > Can you pleae work directly with Nelson in te

Re: New function xpalloc in module xalloc

On Sun, Apr 4, 2021 at 2:17 AM Marc Nieper-Wißkirchen wrote: > > GCC prints the following warning when compiling the new code: > > lib/xmalloc.c: In function 'xpalloc': > lib/xmalloc.c:132:64: warning: comparison of integer expressions of different > signedness: 'long unsigned int' and 'idx_t' {a

Missing c_isdigit with Asan and UBsan builds

Hi Everyone, I'm building libtasn1-4.16.0 on an Apple M1. I'm testing under Asan and UBsan due to a couple of failed self tests. Both Asan and UBsan libtasn1 link is failing with: Undefined symbols for architecture arm64: "_c_isdigit", referenced from: __asn1_expand_object_id in parser_au

Re: results with TinyCC/x86

On Wed, Mar 3, 2021 at 8:37 PM Bruno Haible wrote: > > On a x86_64 glibc system, building a Gnulib testdir with tcc (configured to > produce x86 code: './configure --cpu=x86 --triplet=i386-linux-gnu') gives > a number of test failures: > > FAIL: test-binary-io.sh > FAIL: test-canonicalize > FAIL:

Re: removing permissions for long unused accounts?

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 > change my mind about this, we can work out a new solution. > > Can you pleas

Re: Fix distinction of 32-bit/64-bit mode with xlc 13.1.3 on AIX

Hi Bruno, On Sun, Feb 14, 2021 at 9:50 PM Bruno Haible wrote: > > Starting with xlc version 13, this compiler defines the preprocessor macro > _ARCH_PPC64 also in 32-bit builds. See: > > $ xlc -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.. > $ echo > empty

Re: Possible bug in configure script

On Tue, Jan 26, 2021 at 12:32 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > > Jeffrey Walton wrote: > > > > Placing flags in CC breaks other scripts. For example, this no longer > > > > works: > > > > > > > > if [[ ! $(com

Re: Possible bug in configure script

On Mon, Jan 25, 2021 at 8:41 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > Placing flags in CC breaks other scripts. For example, this no longer works: > > > > if [[ ! $(command -v "${CC}") ]]; then > > echo "The com

Re: Possible bug in configure script

On Mon, Jan 25, 2021 at 5:49 PM Bruno Haible wrote: > > Hi, > > Peter Dyballa wrote: > > The configure script of wget 1.21.1 seems to have a bug, which becomes > > visible > > at least on old Mac OS X versions which use old GCC 4.2, see this report: > > https://trac.macports.org/ticket/62134. It'

Re: Issue when testing with --as-needed enabled

On Tue, Dec 1, 2020 at 7:56 AM Thomas Andrejak wrote: > > Can you explain what GCC options can interfere with this ? --as-needed caused problems in the past. I think it was a linker bug. On occasion you needed to tame the linker with -Wl,--no-as-needed. The weird thing was, the need for -Wl,--no-

Re: clang++ 11 compilation issues

On Tue, Jan 12, 2021 at 3:19 PM Bruno Haible wrote: > > Hi Alexandre, > > > I'm upgrading a project that used a 8-month-old copy of gnulib to > > today's version > > Since then, gnulib has improved its support for clang. > > > I compile with -Werror. > > Gnulib generally does not support -Werror o

  1   2   3   >