Re: stack module

On 5/23/20 3:06 PM, Bruno Haible wrote: > How about this instead? Thanks, good point about the danger. Also, I forgot to include verify.h. I tightened up the commentary, folded in Marc's suggestion, and installed the attached. >From 2df56dc44200074077ebace04079ac4b0a34e4fc Mon Sep 17 00:00:00 200

Re: valgrind-tests and suppression files

On Sat, May 23, 2020 at 5:40 PM Marc Nieper-Wißkirchen wrote: > > Is there any built-in support in the valgrind-tests module for > suppression files? For example, if I want to run my tests under > valgrind (if available), I write > > LOG_COMPILER = $(VALGRIND) > > or, in case I use libtool, > > LO

Re: Fix calloc.m4 test

On 5/23/20 2:53 PM, Bruno Haible wrote: > Does this look like a reportable bug? :-) Absolutely!

Re: stack module

Hi Paul, > Something like the attached? This documentation is quite misleading: +/* Check E's value at runtime, and report an error and abort if not. + However, do nothing if NDEBUG is defined; in this case behavior is because the "do nothing" is an understatement. 'assume' is a dangerous

Re: Fix calloc.m4 test

Hi Paul, > Unfortunately Vincent Lefevre is correct that the C Standard allows calloc > (SIZE_MAX, 2) to succeed on a hypothetical machine that actually can allocate > that amount of memory. This could in theory occur on a machine that doesn't > have > a flat address space. > > A program like th

valgrind-tests and suppression files

Is there any built-in support in the valgrind-tests module for suppression files? For example, if I want to run my tests under valgrind (if available), I write LOG_COMPILER = $(VALGRIND) or, in case I use libtool, LOG_COMPILER = $(LIBTOOL) --mode=execute $(VALGRIND) But how to add valgrind supp

Re: stack module

Am Sa., 23. Mai 2020 um 22:51 Uhr schrieb Paul Eggert : > > On 5/23/20 10:38 AM, Marc Nieper-Wißkirchen wrote: > > But if "affirm" is fine with you, I would love to see it in a module. > > Either in verify or assure or in a new module named affirm. > > Something like the attached? That would be a

Re: stack module

On 5/23/20 10:38 AM, Marc Nieper-Wißkirchen wrote: > But if "affirm" is fine with you, I would love to see it in a module. > Either in verify or assure or in a new module named affirm. Something like the attached? diff --git a/lib/assure.h b/lib/assure.h index 8ea2f6e48..2f1326027 100644 --- a/lib

Re: Fix memleak in getdelim.m4

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 these -fsanitize options have the effect that the resulting executa

Re: Fix calloc.m4 test

On 5/23/20 11:48 AM, Bruno Haible wrote: > 2) It has estimated that the second call would return a non-NULL pointer, > although the address space does not allow this. > Reported at . But some > people claim it is not a bug. Paul, can you

Fix calloc-gnu configure results

Tim Rühsen wrote: > - gcc-10 with unset CFLAGS (*.gcc-10) > And the same set with -fsanitize... (*.sanitize). Looking at the differences between config.cache for the gcc-10 without and with sanitizers, there are some changes that are due to present vs. missing -O2 options (gl_cv_c_inline_effective

Fix invalid use of __builtin_isnanf and __builtin_isnanl

Tim Rühsen wrote: > - gcc-10 with unset CFLAGS (*.gcc-10) > - clang-10 with unset CFLAGS (*.clang-10) Another difference between these test results is this: -gl_cv_func_isnanf_no_libm=${gl_cv_func_isnanf_no_libm=yes} -gl_cv_func_isnanf_works=${gl_cv_func_isnanf_works=yes} -gl_cv_func_isnanl_no_li

Fix calloc.m4 test

Tim Rühsen wrote: > - gcc-10 with unset CFLAGS (*.gcc-10) > - clang-10 with unset CFLAGS (*.clang-10) Comparing these two results, there is a difference: -ac_cv_func_calloc_0_nonnull=${ac_cv_func_calloc_0_nonnull=yes} +ac_cv_func_calloc_0_nonnull=${ac_cv_func_calloc_0_nonnull=no} Why this test r

Fix exponentl.m4 test

Tim Rühsen wrote: > Attached is the config.log and config.cache for > - gcc-9 with unset CFLAGS (*.gcc-9) > - clang-9 with unset CFLAGS (*.clang-9) > - gcc-10 with unset CFLAGS (*.gcc-10) > - clang-10 with unset CFLAGS (*.clang-10) > > And the same set with -fsanitize... (*.sanitize). Thanks, tha

Re: stack module

Hi Paul, Am Sa., 23. Mai 2020 um 19:33 Uhr schrieb Paul Eggert : > Probably not for -O0. I'm not so sure for -Og. Either way, we shouldn't rely > on > GCC's current behavior in this area as it is neither documented nor guaranteed > to stay the same. Agreed. > > #include > > #include "verify.h

Re: stack module

On 5/23/20 9:54 AM, Marc Nieper-Wißkirchen wrote: > Sure, but not in "-O0" or "-Og" builds, I think. Or am I mistaken? Probably not for -O0. I'm not so sure for -Og. Either way, we shouldn't rely on GCC's current behavior in this area as it is neither documented nor guaranteed to stay the same.

Re: [gnu.org #1534539] Re: Licensing issues for gendocs_template_min

Bruno Haible writes: > Thanks. Pushed. Great, thanks! Asher -- : The following (relative to AutoSplit 1.03) attempts to please everyone : and perhaps pleases no one: I think that's way cool. -- Larry Wall in <199709292015.naa09...@wall.org> GPG fingerprint: 38F3 975C D173 40

Re: stack module

Marc Nieper-Wißkirchen wrote: > > I was expecting that you write > > > > struct > > { > > void *base; ... > > } > > This removes type safety. The benefit of the current approach is that > stack types of different types are not compatible. Indeed. Yes, it's a difficult trade-off between

Re: stack module

Am Sa., 23. Mai 2020 um 18:44 Uhr schrieb Paul Eggert : > > On 5/23/20 8:55 AM, Marc Nieper-Wißkirchen wrote: > > A combination of assure and assume would be helpful: > > > > #define checked_assume(X) do { assure (X); assume (X); } while (0) > > No, because the compiler is entitled to optimize away

Re: stack module

On 5/23/20 8:55 AM, Marc Nieper-Wißkirchen wrote: > A combination of assure and assume would be helpful: > > #define checked_assume(X) do { assure (X); assume (X); } while (0) No, because the compiler is entitled to optimize away the 'assure (X)' in this case. I installed the attached to try to e

Re: coreutils and GCC -fanalyzer

On 23.05.20 18:08, Paul Eggert wrote: > On 5/23/20 8:56 AM, Pádraig Brady wrote: >> Note -Wanalyzer... flags are ineffective without -fanalyzer. >> Also -Wanalyzer-too-complex (now auto enabled by gnulib) is currently quite >> problematic with -fanalyzer. > > Hmm, that's odd, since I recall gettin

Re: coreutils and GCC -fanalyzer

On 5/23/20 8:56 AM, Pádraig Brady wrote: > Note -Wanalyzer... flags are ineffective without -fanalyzer. > Also -Wanalyzer-too-complex (now auto enabled by gnulib) is currently quite > problematic with -fanalyzer. Hmm, that's odd, since I recall getting more warnings with those flags enabled. Perha

Re: stack module

Am Sa., 23. Mai 2020 um 17:39 Uhr schrieb Paul Eggert : > > On 5/23/20 7:36 AM, Marc Nieper-Wißkirchen wrote: > > The verify also contains a runtime check `assume', which uses > > __builtin_unreachable if available to help the compiler in optimizing > > modes. > > I wouldn't call 'assume (X)' a "r

Re: Easy Accurate Reading and Writing of Floating-Point Numbers

Am Sa., 23. Mai 2020 um 16:52 Uhr schrieb Bruno Haible : > > In a future version, I may add a flag to select between %e, %f, and %g. > > Hmm, that route is likely going the path to sprintf: First a flag to > select among %e, %f, %g. Then an optional width. Then a flag to select > whether to fill w

Re: stack module

On 5/23/20 7:36 AM, Marc Nieper-Wißkirchen wrote: > The verify also contains a runtime check `assume', which uses > __builtin_unreachable if available to help the compiler in optimizing > modes. I wouldn't call 'assume (X)' a "runtime check". It's more an anti-runtime-check. 'assume (X)' is a di

Re: Easy Accurate Reading and Writing of Floating-Point Numbers

On 5/23/20 5:26 AM, Marc Nieper-Wißkirchen wrote: > I sent such an assignment request to the FSF a few days ago but > haven't heard back from them yet. It may take a few days more. If you don't hear back in a couple of weeks, please let us know. Thanks for writing that, by the way. It's a good im

Re: Easy Accurate Reading and Writing of Floating-Point Numbers

Hello Marc, > In a future version, I may add a flag to select between %e, %f, and %g. Hmm, that route is likely going the path to sprintf: First a flag to select among %e, %f, %g. Then an optional width. Then a flag to select whether to fill with spaces or with zeroes. If you go that route, it's

Re: stack module

Am Sa., 23. Mai 2020 um 16:02 Uhr schrieb Bruno Haible : > I was expecting that you write > > struct > { > void *base; ... > } This removes type safety. The benefit of the current approach is that stack types of different types are not compatible. > Then macro should better be called S

Re: stack module

Hi Marc, > > In Gnulib, we usually avoid extensive use of multi-line macros, because > > it hampers debuggability. Here, however, one needs macros, in order to > > accommodate the TYPE argument, which is not necessarily compatible to 'void > > *'. > > Nevertheless, we would try to put as much cod

Re: stack module

Hi Bruno, > In Gnulib, we usually avoid extensive use of multi-line macros, because > it hampers debuggability. Here, however, one needs macros, in order to > accommodate the TYPE argument, which is not necessarily compatible to 'void > *'. > Nevertheless, we would try to put as much code as poss

Re: stack module

Hi Marc, > Alternatively, one could implement a universally usable stack through > the following header file (mimicking somewhat C++ templates). What do > you think? It will be a lot faster than using the general list modules > of Gnulib. I agree that a generic 'stack' module is useful. I also ag

Re: Easy Accurate Reading and Writing of Floating-Point Numbers

Hi Bruno, [...] > The only (tiny) issue is a matter of style: Two of the new module files don't > end in a newline. In Gnulib, we try to let every non-empty text file end in a > newline, since "cat FILE" and "sed -e ... FILE" work better this way. I will correct this when I send you the final pa

Re: Easy Accurate Reading and Writing of Floating-Point Numbers

Hi Marc, Marc Nieper-Wißkirchen wrote: > Please see the attached patch file, my first attempt (and first > contribution to Gnulib). The patch looks all correct. The only (tiny) issue is a matter of style: Two of the new module files don't end in a newline. In Gnulib, we try to let every non-empt

Re: find_in_given_path(): not handling directories properly

Hi Paul, > In gnulib commit 7b1de4a62f876: > > commit 7b1de4a62f8766787160f785217671b074e0f0f2 > Author: Bruno Haible > Date: 2020-04-10 15:57:10 +0200 > > findprog, relocatable-prog: Ignore directories during PATH search. > > Reported by Frederick Eaton via Dmitry Goncharo

Re: installing patches with git

Karl Berry wrote: > But can I ask someone else > to install it, please? Bruno? I have no faith in my ability to use git > in expected ways. Installing a patch into Gnulib is indeed a bit complicated, due to the fact that we use a ChangeLog file and we try to use the same title and message with git