RE: [PATCH] Basic support for checking NFSv4 ACLs in Linux

Hi Andreas, - I do not quite understand. I did not bother copying the who value into extra buffer hence I am using strncmp instead of strcmp and therefore can't use strlen. The checks are sufficient there. - I will put your ROUNDUP code in there. - Is anyone willing to help me with the linker pr

[PROPOSED 4/4] explicit_bzero: implement via memset_explicit

* lib/explicit_bzero.c (explicit_bzero): Simplify by just calling memset_explicit. * m4/explicit_bzero.m4 (gl_PREREQ_EXPLICIT_BZERO): Now a no-op. * modules/explicit_bzero (Depends-on): Add memset_explicit. (configure.ac): No need to worry about gl_PREREQ_EXPLICIT_BZERO. --- ChangeLog

[PROPOSED 0/4] memset_explicit patches

Here's a proposed set of patches to add support for C23's memset_explicit function, along with the corresponding fallout in Gnulib. The idea is to prefer memset_explicit, but continue to support explicit_bzero (which is not marked as obsolescent, as it's too soon for that). Comments welcome. Pau

[PROPOSED 3/4] explicit_bzero: memset_explicit is standard

* doc/glibc-functions/explicit_bzero.texi: Say that memset_explicit is preferred in new code. --- ChangeLog | 4 doc/glibc-functions/explicit_bzero.texi | 4 2 files changed, 8 insertions(+) diff --git a/ChangeLog b/ChangeLog index 2d29d1f646..ea76fef399 10

[PROPOSED 1/4] memset_explicit: new module

* doc/posix-functions/memset_explicit.texi, lib/memset_explicit.c: * m4/memset_explicit.m4, modules/memset_explicit: * modules/memset_explicit-tests, tests/test-memset_explicit.c: New files. * lib/string.in.h (memset_explict): New decl. * m4/string_h.m4 (gl_STRING_H, gl_STRING_H_REQUIRE_DEFAULTS) (

[PROPOSED 2/4] read-file: use memset_explicit

* lib/read-file.c (fread_file, read_file): Use memset_explicit instead of explicit_bzero. * modules/read-file (Depends-on): Depend on memset_explicit instead of on explicit_bzero. --- ChangeLog | 6 ++ lib/read-file.c | 12 ++-- modules/read-file | 2 +- 3 files changed, 13

[PATCH] explicit_bzero: add poison

* m4/string_h.m4 (gl_STRING_H): Poison explicit_bzero. This was inadvertently omitted when explicit_bzero was added. --- ChangeLog | 6 ++ m4/string_h.m4 | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 5436871fea..14283da87e 100644 --- a/

Re: [PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

Arsen Arsenović wrote: > > If you do this, you lose an interesting use-case: Imagine a developer > > who makes changes to jitter (maybe Luca himself) and wants to test the > > changes with different versions of poke (which reside in different > > directories). > > But wouldn't Luca just run someth

Re: [PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

Bruno Haible writes: > If you do this, you lose an interesting use-case: Imagine a developer > who makes changes to jitter (maybe Luca himself) and wants to test the > changes with different versions of poke (which reside in different > directories). But wouldn't Luca just run something like:

Re: [PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

Arsen Arsenović wrote: > --jitter-srcdir doesn't really even make > sense in autopull? My thinking is that autopull is pretty fixed on > operate on submodules AFAIU (seemingly backed up by --jitter-srcdir > previously being ignored for the pull stage anway), so just removing all > of that logic an

Re: [PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

Evening, Bruno Haible writes: >> * build-aux/bootstrap: Regenerate. > > Thanks; I pushed that part in your name. Thanks! > Yes, all 4 of bootstrap_option_hook, bootstrap_print_option_usage_hook, > bootstrap_post_pull_hook, bootstrap_post_import_hook then deal with > JITTER_SRCDIR in one form o

Re: [PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

Hi Arsen, Arsen Arsenović wrote: > * build-aux/bootstrap: Regenerate. Thanks; I pushed that part in your name. > The solution proposed here lets Jitter be integrated via: > > # Set up the Jitter path. > bootstrap_srcdirs_hook () { > # Pass JITTER_SRCDIR to subprocesses. > export JIT

Re: explicit_bzero and -std=c99

Paul Eggert wrote: > > 2) Is there no other way to implement explicit_bzero without 'asm'? > > There is a another fallback code using volatile pointers, but I'm not > > sure it really has the same semantics. > > That fallback should work, though it's a bit slower. I'm afraid that the

Re: explicit_bzero and -std=c99

On 2022-11-27 10:05, Paul Eggert wrote: It should, yes. That's a reasonable portability test, so long as Gnulib continues to support C99. Ah, Bruno has corrected me on this. Although compiling with -std=c99 is OK for some parts of Gnulib, it's not OK for all. In this particular case the fix i

Re: explicit_bzero and -std=c99

On 2022-11-27 03:27, Simon Josefsson via Gnulib discussion list wrote: 1) Does gnulib support building with gcc -std=c99? I think we should, but it could have documented missing functionality or breakage. It should, yes. That's a reasonable portability test, so long as Gnulib continues to su

Re: explicit_bzero and -std=c99

Hi Simon, > 1) Does gnulib support building with gcc -std=c99? I think we should, > but it could have documented missing functionality or breakage. No, Gnulib does not support this. We freely use GCC extensions, such as ({...}) or asm, usually conditionalized with defined __GNUC__ || defined _

[PATCH] bootstrap: Provide a hook for submodule _SRCDIR setup

* top/bootstrap-funclib.sh (bootstrap_srcdirs_hook): Define a hook for user-specified submodule directory paths. * top/bootstrap: Call bootstrap_srcdirs_hook after setting up GNULIB_SRCDIR. * top/autogen.sh: Likewise. * top/autopull.sh: Likewise. * build-aux/bootstrap: Regenerate. --- Hi there, Wh

explicit_bzero and -std=c99

Hi. We got a bug report about a build failure (see below), and I'm wondering: 1) Does gnulib support building with gcc -std=c99? I think we should, but it could have documented missing functionality or breakage. 2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for GCC, which isn