Re: Build issues with gettext 0.20.2 and 0.21 on Solaris 10 i386 with 64 bit

On Tue, Dec 1, 2020 at 3:15 PM Dagobert Michelsen wrote: > > Hi Bruno, > > Am 01.12.2020 um 20:46 schrieb Bruno Haible : > > But the $host_cpu value from the canonical triplet $host allows to do so. > > This is the triplet I get for my 64 bit build: > > checking build system type... i386-pc-solari

Re: exotic CPU hardware

On Fri, Dec 4, 2020 at 3:49 PM Bruno Haible wrote: > > Paul Eggert wrote: > > update it to mention two current platforms where sizeof(size_t) == > > sizeof(ptrdiff_t) but index arithmetic does not behave in the usual way > > Are these *current* platforms? The currently sold Unisys ClearPath Dorado

Re: checking against signed integer overflow

On Sat, Dec 5, 2020 at 10:04 AM Bruno Haible wrote: > > ... > Now, let me ask the question "What compiler options would a distro have to > provide, in order to globally enable signed integer overflow checks?" > (like -D_FORTIFY_SOURCE=2, which many distro vendors now use). > > Through some experim

Re: checking against signed integer overflow

On Sat, Dec 5, 2020 at 1:07 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > You might also checkout an overflow library. For the C language, > > safe_iop is available. > > Gnulib's INT_*_WRAPV macros are similar. [1] > > > -ftrapv is for defective prog

Re: checking against signed integer overflow

On Sun, Dec 6, 2020 at 1:06 PM Paul Eggert wrote: > ... > > So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' > > and > > '-ftrapv' both work. The former generates better code, whereas the latter > > has > > less surprising behaviour (an abort() is a better response tha

Re: checking against signed integer overflow

On Sun, Dec 6, 2020 at 11:19 PM Bruno Haible wrote: > > Paul Eggert wrote: > > At this point it would be better for integer arithmetic overflow to > > generate SIGFPE in some way that a signal handler could tell the > > difference, but > > this is not a hill I'm prepared to die on and if it requi

Re: new modules execve, execvpe, execvp, execv, execl, execle, execlp

On Sat, Dec 26, 2020 at 8:53 AM Bruno Haible wrote: > > ... > All of these problems are fixed with these new Gnulib modules. > Just an FYI in case you have not hit this wall (yet?)... The exec family, posix_spawn and friends are _not_ available on all Apple platforms. Be sure to check availabilit

Re: Apple embedded OSes

On Sun, Dec 27, 2020 at 7:20 AM Bruno Haible wrote: > > Hi Jeffrey, > > > Just an FYI in case you have not hit this wall (yet?)... The exec > > family, posix_spawn and friends are _not_ available on all Apple > > platforms. Be sure to check availability before using them. > > > > For example, the

Re: memalign: Work around Solaris bug

On Thu, Dec 31, 2020 at 4:21 PM Bruno Haible wrote: > > On Solaris 11.4, Solaris OpenIndiana, Solaris OmniOS, I see this test failure: > > ../../gltests/test-memalign.c:51: assertion 'aligned2_blocks[i] != NULL' > failed > FAIL test-memalign (exit status: 262) > > Apparently memalign() does not s

Re: Wget 1.21 and PowerMac results

FYI... Sent to the bug-wget list. On Fri, Jan 1, 2021 at 1:38 PM Jeffrey Walton wrote: > > Hi Everyone, > > Here are the results of building Wget 1.21 on an old PowerMac G5. > > gcc -DHAVE_CONFIG_H -I. -I../src > -DDEFAULT_TEXT_DOMAIN=\"wget-gnulib\" -I/usr/

Re: [PATCH] Use https:// instead of git://.

On Sat, Jan 9, 2021 at 7:10 PM Simon Josefsson via Gnulib discussion list wrote: > > I have pushed this, and I also updated the link from > https://www.gnu.org/software/gnulib/ > > /Simon > > * build-aux/bootstrap (default_gnulib_url): Ditto. > * config/srclistvars.sh: Ditto. > * doc/gnulib-readme

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

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: 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: 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 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: 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: 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: 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:

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: 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

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: 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: 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: 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: 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-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_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: _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 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 > >

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: 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

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?

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 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 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: 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: 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: 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: "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: 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: [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: 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: 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: 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: 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: [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: -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: 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: FAIL: test-rwlock1 on 32-bit ARM

On Tue, Feb 6, 2018 at 12:11 PM, Bruno Haible wrote: > Hi, > > Jeffrey Walton wrote: >> > FAIL: test-rwlock1 >> > == >> > >> > Unexpected outcome 3 >> > FAIL test-rwlock1 (exit status: 134) >> &

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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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: 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: 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 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: 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: 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: 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: 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: 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: 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: [bug-libunistring] Unistring 0.9.10 and Undefined Behavior sanitizer findings

On Fri, Mar 8, 2019 at 6:36 PM Bruno Haible wrote: > ... > > I'm pushing the attached patches. Thanks Bruno, got them. 0.9.10 tested good with them. (I should be starting on -fsanitize=address this weekend. Address Sanitizer is a little trickier because I've seen findings that I could not expla

Gnulib use of -Wl,-rpath

Hi Everyone, I'm trying to track down a failure in building libidn. IDN uses Gnulib, and IDN's 'make check' is failing on the Gnulib test runner. IDN's earlier test runners pass, and I think the issue is related Gnulib. First, here is a successful runner. IDN's runners 1 and 2 do this: libtool:

Re: Gnulib use of -Wl,-rpath

On Tue, May 14, 2019 at 5:22 AM Bruno Haible wrote: > > Hi, > > Jeffrey Walton wrote: > > Second, here is a failed Gnulib runner. IDN's runner 3 does this: > > > > libtool: link: gcc -g2 -O2 -fsanitize=address -fno-omit-frame-pointer > > -march=native

ctype.h:192: error: parse error before '{' token

Hi Everyone, I'm trying to build cURL, Git, Wget and several other utilities on some ancient systems. We still use early Fedora and early Ubuntu VM's to regression test. We claim to support GCC 2.95 and above. We test on early Fedora and early Ubuntu to verify the claim. I'm catching a lot of bui

Re: ctype.h:192: error: parse error before '{' token

On Wed, Jul 17, 2019 at 6:49 PM Jeffrey Walton wrote: > > I'm trying to build cURL, Git, Wget and several other utilities on > some ancient systems. We still use early Fedora and early Ubuntu VM's > to regression test. We claim to support GCC 2.95 and above. We test on &g

Re: ctype.h:192: error: parse error before '{' token

On Wed, Jul 17, 2019 at 7:42 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > We claim to support GCC 2.95 and above. > > That's a tough claim, and you can't count on gnulib to help you on that > claim. Ack, thanks. > This means, by using gnulib you can cer

Re: ctype.h:192: error: parse error before '{' token

On Wed, Jul 17, 2019 at 9:03 PM Paul Eggert wrote: > > Jeffrey Walton wrote: > > This fixes the issue for GCC 3.1 (Fedora 1) and GCC 3.3 (Ubuntu 4). > > I don't see how that patch could fix the issue for GCC 3.1, since it simply > changes a test to check for GCC 3.4

Re: ctype.h:192: error: parse error before '{' token

On Wed, Jul 17, 2019 at 9:19 PM Paul Eggert wrote: > > Jeffrey Walton wrote: > > It looks like the glibc macro is a little simpler and lacks the attributes: > > Thanks. Can you give the preprocessor output for a declaration that fails with > Gnulib? __attribute__ ((nothrow)

Re: ctype.h:192: error: parse error before '{' token

On Wed, Jul 17, 2019 at 9:41 PM Jeffrey Walton wrote: > > On Wed, Jul 17, 2019 at 9:19 PM Paul Eggert wrote: > > > > Jeffrey Walton wrote: > > > It looks like the glibc macro is a little simpler and lacks the > > > attributes: > > > > Th

autopoint: ... gettext-0.20 ... is too old

Hi Everyone, I'm trying to test Gnulib according to https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00117.html. I've cloned the latest Gnulib. I'm running this command: GNULIB_DIR=gnulib GNULIB_TEST_DIR=gnulib_test git clone ... cd "$GNULIB_DIR" if ! ./gnulib-tool --create-testdir --d

autopoint: ... gettext-0.20 ... is too old

Hi Everyone, I'm trying to test Gnulib according to https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00117.html. I've cloned the latest Gnulib. I'm running this command:

Re: autopoint: ... gettext-0.20 ... is too old

On Thu, Jan 30, 2020 at 9:50 AM Bruno Haible wrote: > > Hi Jeffrey, > > > if ! ./gnulib-tool --create-testdir --dir=../"$GNULIB_TEST_DIR" > > --single-configure; > > ... > > ... > > top/GNUmakefile > > top/README-release > > top/maint.mk > > executing autopoint --force > > autopoint: *** T

error: use of undeclared identifier '__noreturn__'

Hi Everyone, An FYI since I saw some chatter about Noreturn recently... I'm building GnuTLS 3.6.12 release tarball on OS X 10.9. GnuTLS has a copy of gnulib. The compile is failing: gcc -DHAVE_CONFIG_H -I. -I.. -I./gl -I./gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./..

Fwd: GnuTLS 3.6.12 patch for OS X 10.9

FYI... -- Forwarded message - From: Jeffrey Walton Date: Mon, Feb 3, 2020 at 3:12 AM Subject: GnuTLS 3.6.12 patch for OS X 10.9 To: Hi Everyone, I'm working from the GnuTLS 3.6.12 release tarball on OS X 10.9. The build is failing due to the handling of _Noreturn in con

Re: Fwd: GnuTLS 3.6.12 patch for OS X 10.9

On Mon, Feb 3, 2020 at 4:28 PM Paul Eggert wrote: > > Looking at the online Clang manuals, it appears that Clang started > supporting _Noreturn starting with 3.5.0. So does the attached > (untested) patch work for you? If not, please advise. Thanks Paul. I think there is a small issue. There are

Re: Fwd: GnuTLS 3.6.12 patch for OS X 10.9

On Mon, Feb 3, 2020 at 4:28 PM Paul Eggert wrote: > > Looking at the online Clang manuals, it appears that Clang started > supporting _Noreturn starting with 3.5.0. So does the attached > (untested) patch work for you? If not, please advise. If interested, I can provide SSH access to a PowerMac r

Re: Fwd: GnuTLS 3.6.12 patch for OS X 10.9

On Mon, Feb 3, 2020 at 9:32 PM Paul Eggert wrote: > ... > How about the attached (untested) patch instead? It looks at > __apple_build_version__. Ack, tested OK on OS X 10.9 and a Linux smoke test. I was able to test _Noreturn.h through GnuTLS. I was not able to test gnulib-common.m4. (I'm still

Re: Fwd: GnuTLS 3.6.12 patch for OS X 10.9

On Mon, Feb 3, 2020 at 9:32 PM Paul Eggert wrote: > > On 2/3/20 3:00 PM, Jeffrey Walton wrote: > > > Or, you can use __has_attribute(_Noreturn). __has_attribute(_Noreturn) > > behaves as expected. > > It isn't documented to work, and it doesn't work for me wit

GetText 1.20.1 and libgettextlib.so: undefined reference to `libiconv' (and friends)

Hi Everyone, I'm building GetText 1.20.1 from sources on NetBSD. msgcmp is failing: /bin/sh ../libtool --tag=CC --mode=link gcc -g2 -O2 -fPIC -pthread -L/usr/local/lib -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/usr/local/lib -Wl,--enable-new-dtags -o msgcmp msgcmp-msgcmp.o msgcmp-msgl-fsearch.o libgett

Re: GetText 1.20.1 and libgettextlib.so: undefined reference to `libiconv' (and friends)

On Wed, Feb 5, 2020 at 4:02 AM Jeffrey Walton wrote: > > Hi Everyone, > > I'm building GetText 1.20.1 from sources on NetBSD. msgcmp is failing: > > /bin/sh ../libtool --tag=CC --mode=link gcc -g2 -O2 -fPIC -pthread > -L/usr/local/lib -Wl,-R,'$ORIGIN/../l

Re: restrict

On Sun, Feb 9, 2020 at 10:03 PM Bruno Haible wrote: > ... > Which function declarations could therefore profit from the 'restrict' > keyword? [SNIP ...] I think the case of interest is subobjects of arrays: char a[] = "Hello World"; char* b = a+5; memcpy(a,b,5) would get you in trouble

Re: fstrcmp: memory is not reclaimed on exit

On Sun, Feb 16, 2020 at 7:53 AM Bruno Haible wrote: > > ... > > I agree, I would like to be able to explicitly release the memory. But > > I can't see any API to do that in fstrcmp.c. Is this one ok? > > The GNU Coding Standards [1] tell us to not worry about this situation. > However, > the al

Use of chmod in gnulib

Hi Everyone, According to the Autoconf manual, commands like 'chmod +x' should be avoided in favor of 'chmod a+x'. I believe the same applies to 'chmod -w' and friends. Also see https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html. It looks like the

Re: Use of chmod in gnulib

On Sun, Mar 22, 2020 at 3:18 PM Paul Eggert wrote: > > On 3/22/20 10:17 AM, Jeffrey Walton wrote: > > > According to the Autoconf manual, commands like 'chmod +x' should be > > avoided in favor of 'chmod a+x'. I believe the same applies to '

gnulib-lib/xalloc-oversized.h:45:0: warning: "xalloc_oversized" redefined

Hi Everyone, Would someone please clear this warning before the next release. It is prevalent in some packages, like iconv. In file included from ../gnulib-lib/malloca.h:26:0, from ../gnulib-lib/xmalloca.h:21, from message.c:32: ../gnulib-lib/xalloc-oversized.h:4

Re: gnulib-lib/xalloc-oversized.h:45:0: warning: "xalloc_oversized" redefined

On Sun, Mar 22, 2020 at 7:14 PM Paul Eggert wrote: > > On 3/22/20 3:47 PM, Jeffrey Walton wrote: > > In file included from message.c:31:0: > > ../gnulib-lib/xalloc.h:149:0: note: this is the location of the > > previous definition > > # define xalloc_oversized(n,

Re: gnulib-lib/xalloc-oversized.h:45:0: warning: "xalloc_oversized" redefined

On Sun, Mar 22, 2020 at 8:32 PM Bruno Haible wrote: > > Paul Eggert wrote: > > Gnulib's lib/xalloc.h has not had that line since 2011. Sounds like you > > have an > > old copy and need to upgrade. > > Yes, GNU libiconv and GNU gettext still have an old copy of xalloc.h. It's > harmless, only prod

Re: 32bit or LTO movemail build fails on macOS

On Tue, Mar 24, 2020 at 10:58 PM Paul Eggert wrote: > > Thanks for the bug report. Does the attached patch to getopt-pfx-core.h fix > the > bug for you? > > I'll CC: this to bug-gnulib and to Zack Weinberg, who wrote that file. For > those > new to this thread, please see

  1   2   >