Re: Module suggestion: Atomic operations

Hi Marc, > C11 has introduced atomic types and atomic operations. When they are not > available, one can use locks/mutexes instead. > > It would be nice if there was a Gnulib module that abstracts over this, > much like the threadlib module and friends abstract over a specific > threading

Re: stack module

Paul Eggert wrote: > I don't want to encourage programmers to supply an E with side effects, as > side > effects are trouble here. +1

Re: portability of fopen and 'e' (O_CLOEXEC) flag

Tim Rühsen wrote on 2020-05-12: > > How about using open() with O_CLOEXEC, and then fdopen()? > > Thanks. Sure, this is possible. Doing so at dozens of places (or more) > asks for an implementation in gnulib :) Additionally, gnulib is the right place to do this because - as Eric said - the 'e'

Re: stack module

On 5/24/20 1:17 AM, Marc Nieper-Wißkirchen wrote: > You > wrote for the affirm macro that if NDEBUG is defined that the behavior > is undefined if E has side effects. That's not true as long as E does > not evaluate to false. We can *make* it true, by fiat. :-) I don't want to encourage

open, openat: really support O_CLOEXEC

While working on support for mode 'e' in fopen(), I noticed that on macOS 10.13 open with O_CLOEXEC creates a file descriptor that does *not* have the FD_CLOEXEC flag set. This was meant to be implemented since 2017-08-14, but it does not work. The problem is in this code (lib/open.c): fd =

Re: find_in_given_path(): not handling directories properly

On Fri, 2020-05-22 at 01:05 -0400, Paul Smith wrote: > However, the same issue exists in lib/findprog-in.c, in the > find_in_given_path() (which is what GNU make actually uses), and that > function wasn't updated by the above commit. Thanks for addressing this, Bruno!

Update to docs etc.

It's been pointed out on the GNU make lists that by including gnulib content we've effectively updated our minimum required compiler from C90 to C99. That may be acceptable, but I think the gnulib docs (at least), if not gnulib-tool, should make clear that AC_PROG_CC_C99 (at least) needs to be

Module suggestion: Atomic operations

C11 has introduced atomic types and atomic operations. When they are not available, one can use locks/mutexes instead. It would be nice if there was a Gnulib module that abstracts over this, much like the threadlib module and friends abstract over a specific threading implementation. What I am

fopen: Fix the trailing slash workaround

When I add a couple of more unit tests to the 'fopen' tests, I see a test failure on Solaris 9: $ ./test-fopen ../../gltests/test-fopen.h:74: assertion 'fopen ("./", "r+") == NULL' failed Abort (core dumped) This patch fixes it. 2020-05-24 Bruno Haible fopen: Fix the trailing slash

Re: Bug

[CCing bug-m4] Hi, Rahmad Alamsyah Nazaruddin wrote: > I got this issue '#error "please port gnulib freadhead.c to your platform! > Look at the definition of fflush, fread, ungetc on your system' > How can i fix this ? I fail install on M4 Thank you for reporting this.

Bug

Hello, I got this issue '#error "please port gnulib freadhead.c to your platform! Look at the definition of fflush, fread, ungetc on your system' How can i fix this ? I fail install on M4

Re: Fix memleak in getdelim.m4

Hi Bruno, On 23.05.20 22:47, Bruno Haible wrote: > Tim Rühsen wrote: >> - clang-10 with unset CFLAGS (*.clang-10) >> >> And the same set with -fsanitize... (*.sanitize). > > The other differences between the configure results without and with > sanitizers > can be explained by the fact that

Bundling Gnulib tests with an application

When an application bundles Gnulib tests in its distribution, say in a folder named gnulib-tests, and has its own suite of Automake tests in the folder tests, the console output by Automake when running make check is suboptimal because it will print something like

Re: stack module

Thank you very much, Paul! One bit of the commentary is still misleading, though, I think. You wrote for the affirm macro that if NDEBUG is defined that the behavior is undefined if E has side effects. That's not true as long as E does not evaluate to false. Marc Am So., 24. Mai 2020 um 04:14

Re: Fix calloc.m4 test

> > Does this look like a reportable bug? :-) > > Absolutely! > I've reported it at . Bruno