[PATCH] read-file-test: pacify --enable-gcc-warnings

* tests/test-read-file.c (test_read_file): Now static. --- ChangeLog | 3 +++ tests/test-read-file.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index b7b39272f..4d240e0d4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,8 @@ 2020-05-3

[PATCH] tempname: merge from glibc and coreutils

Also, merge in Gnulib’s more-recent methods of making it easier to share between Gnulib and glibc, and fix a few randomness glitches. * lib/tempname.c: Include libc-config.h, not config.h, if !_LIBC. (__set_errno): Remove; libc-config.h does that for us. Do not include . (__secure_getenv) [_LIBC]:

Re: Bundling Gnulib tests with an application

Marc Nieper-Wißkirchen wrote: > 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 som

Re: getrandom vs. crypto/gc-random

Hi Simon, Thanks for your insights. > Historically, the problem is that for cryptographic purposes, > /dev/random and /dev/urandom can be a really bad choice on many > platforms. This has probably been improved over the years, especially > on the most relevant platforms, but still Indeed. Even

Re: [PATCH] getentropy, getrandom: new modules

Now that we're done with the 'getrandom' module, a fix and a tweak for the 'getentropy' module. 2020-05-31 Bruno Haible getentropy: Enhance tests. * tests/test-getentropy.c (main): Add one more test. * tests/test-unistd-c++.cc: Check the signature of getentropy. 2020-

Re: fnmatch: rely on more gnulib modules

On 5/30/20 5:51 PM, Bruno Haible wrote: > Fixed the 'fnmatch' dependencies like this. Thanks. These fnmatch updates encouraged me to merge glibc master and Gnulib fnmatch as best I could. I installed the attached patch, with the idea of merging this back into glibc someday (the Gnulib code shoul

getrandom: doc and test tweaks

Adding some more precision to the documentation, and tweaking the unit test. 2020-05-31 Bruno Haible getrandom: Doc and test tweaks. * lib/getrandom.c (getrandom): Mention that it never returns 0, and that it sets errno when failing. * tests/test-getrandom.c (m

Re: getrandom: Add support for native Windows

On Sun, May 31, 2020 at 12:26 PM Bruno Haible wrote: > > Native Windows is the only platform without the /dev/random and > /dev/urandom devices; it therefore needs special code. > > Jeffrey Walton wrote: > > On modern Windows systems you should use BCryptGenRandom for the > > material. CryptGenRan

getrandom: Add support for native Windows

Native Windows is the only platform without the /dev/random and /dev/urandom devices; it therefore needs special code. Jeffrey Walton wrote: > On modern Windows systems you should use BCryptGenRandom for the > material. CryptGenRandom is deprecated. Thanks for the pointer. This patch implements

Re: getrandom vs. crypto/gc-random

There is a lot to be said about randomness, but for the purpose of getrandom() and getentropy(), which to my knowledge aren't globally standardized (de-factor or otherwise) and well-specified what semantics re cryptographic properties they should have, I agree it make sense to keep the implementati

Re: getrandom vs. crypto/gc-random

On Sun, May 31, 2020 at 7:23 AM Bruno Haible wrote: > > ... > 3) There is the question whether getrandom() should be based on module > crypto/gc-random. That is, whether the configure script should accept an > option --with-libgcrypt, in order to use libgcrypt when available. > I think the answer

Re: getrandom vs. crypto/gc-random

> 1) The list of random devices, determined through gc-random.m4. > > > To fix that, I > > am thinking that getrandom should remove its dependency on > > crypto/gc-random, and > > should simply use "/dev/urandom" for the nonce device without worrying about > > whether crypto/gc-random would defin

Re: getrandom vs. crypto/gc-random

Paul Eggert wrote: > The remaining issue is "partial overlap with crypto/gc-random". Yes. It has three aspects: 1) The list of random devices, determined through gc-random.m4. > To fix that, I > am thinking that getrandom should remove its dependency on crypto/gc-random, > and > should simply u

fix list of crypto devices for Solaris

Solaris too (even Solaris 9) has /dev/random and /dev/urandom. The manpage credits Linux: An implementation of the /dev/random and /dev/urandom kernel-based random number generator first appeared in Linux 1.3.30. 2020-05-31 Bruno Haible crypto/gc-random: Fix lis

Re: list: fix GCC warnings

> Le 31 mai 2020 à 11:28, Bruno Haible a écrit : > > Hi Akim, > > Thanks for caring about these warnings. Sure! >>* lib/gl_anytreehash_list2.h (gl_tree_search_from_to): Avoid using >>the same variable name in nested scopes. > > 'p' is a poor variable name here. Please, can use you

Re: Apple platforms

Jeffrey Walton wrote: > On Apple platforms, when targeting specific devices like AppleTV, you > should include Apple's . > > You will also need to determine platform > support for function calls like fork(). Not all Apple platforms > provide fork and friends. In GNU, we don't write software for

Re: iterator and const iterator

Hi Akim, In you write: > > Le 3 mai 2020 à 17:17, Bruno Haible a écrit : > > > > There are a couple of GCC warnings on IRIX (CC="gcc -mabi=n32"): > > > > 2) > > ../src/fixits.c: In function `fixits_run': > > ../src/fixits.c:12

Re: type punning in gl_list.hh

Akim Demaille wrote in : > Also, in gnulib, I found this in gl_list.hh: > > /* If there is a next element, stores the next element in ELT, advances >the iterator and returns true. >Otherwise, returns false. */

Re: list: fix GCC warnings

Hi Akim, Thanks for caring about these warnings. > * lib/gl_anytree_list2.h (gl_tree_iterator_free) > (gl_tree_next_node, gl_tree_node_nx_set_value) > (gl_tree_previous_node, gl_tree_next_node): > Mark unused arguments. > * lib/gl_anytree_oset.h (gl_tree_iterator_free): Likewi

list: fix GCC warnings

Hi all, There's one case debatable case: the functions that may actually use the argument depending on macros. For instance static int gl_linked_node_nx_set_value (gl_list_t list _GL_ATTRIBUTE_MAYBE_UNUSED, gl_list_node_t node, const void