Re: Module suggestion: Atomic operations

2020-05-25 Thread Marc Nieper-Wißkirchen
Hi Bruno, Am So., 24. Mai 2020 um 22:54 Uhr schrieb Bruno Haible : > Yes, given that the platform support for these atomic types/operations is > increasing, it would accelerate the adoption if there was a Gnulib module, > like you describe it. Program developers could then adopt > without losing

Re: c99 dependencies

2020-05-25 Thread Bruno Haible
Paul Smith wrote: > 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. Yes. This is documented in [1]. > That may be acceptable, but I think the gnulib docs (at least), if not > gnulib-tool, sho

Re: Module suggestion: Atomic operations

2020-05-25 Thread Bruno Haible
Hi Marc, > One problem with as given is that atomic values have no > destructors. Thus, we cannot simply attach locks to them in a pre-C11 > implementation because there is no place to destroy the locks. Ah... > Thus, we would have to work with a pool of locks shared by all atomic > variables.

explicit_bzero-tests: pacify -Wmissing-declarations

2020-05-25 Thread Bruno Haible
Hi Paul, > * tests/test-explicit_bzero.c (do_secret_stuff, test_stack): > Now static. It's OK to mark 'test_stack' static. But for 'do_secret_stuff', it invites the compiler to inline the function and then to do different optimizations for pass == 1 and pass == 2, which will break the test.

[PATCH] getentropy, getrandom: new modules

2020-05-25 Thread Paul Eggert
* MODULES.html.sh (func_all_modules): * lib/unistd.in.h (getentropy, getrandom): * m4/unistd_h.m4 (gl_UNISTD_H, gl_UNISTD_H_DEFAULTS): * modules/unistd (unistd.h): Add support for getentropy, getrandom. * doc/glibc-functions/getentropy.texi (getentropy): * doc/glibc-functions/getrandom.texi (getran

Re: Module suggestion: Atomic operations

2020-05-25 Thread Marc Nieper-Wißkirchen
Hi Bruno, Am Mo., 25. Mai 2020 um 09:24 Uhr schrieb Bruno Haible : > Pools have the drawback that they add a configuration requirement on the > application: What is the default size of the pool? When to increase the > pool size? By how much? When to shrink the pool? The developer would have > det

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

2020-05-25 Thread Daiki Ueno
Hello Bruno, Bruno Haible writes: > Additionally, gnulib is the right place to do this because - as Eric said - > the 'e' flag is already scheduled for being added to the next POSIX version: > https://www.austingroupbugs.net/view.php?id=411 > > My evaluation of current platform support was incor