Re: Parameterize the memory allocator for the container library

Hi, If I may chime into the discussion, let me remark that local parameterization of the memory allocator is often useful (while the linker approach means a global replacement). For example, part of the program/library may work with an arena allocator (see, e.g. [1] for a general discussion) and

Re: new module 'jit/cache'

Do you have detailed test results/logs? Thanks, Marc Am Di., 19. Dez. 2023 um 23:13 Uhr schrieb Bruno Haible : > My (preliminary) test results: > > The test passes on x86_64, m68k, alpha, s390, s390x, riscv64, loongarch64. > > It fails on some platforms with i386, mips, sparc, arm, arm64 > >

Re: pointer addition and arrays

Am So., 17. Dez. 2023 um 09:50 Uhr schrieb Paul Eggert : > On 2023-12-16 04:42, Marc Nieper-Wißkirchen wrote: > > the problem is if further down in the compiler pipeline, the > > P <= P expression produces some intermediate code that becomes equal to > > code the opt

Re: pointer addition and arrays

Am Fr., 15. Dez. 2023 um 02:00 Uhr schrieb Paul Eggert : > On 12/3/23 05:15, Andreas F. Borchert wrote: > > You will have > > then to possibly live with annoying warnings and odd behaviours. > > The C standard says that when P is a null pointer, P==P must be true > whereas P<=P has undefined

Re: undefined-behavior obstack.c:139

Am So., 3. Dez. 2023 um 10:05 Uhr schrieb Paul Eggert : > On 2023-12-02 01:04, Bruno Haible wrote: > > On the contrary, I will try to find and eliminate such alarms. > > Please don't complicate and/or slow down shared Gnulib code just to > pacify this particular false alarm from Clang. The

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 21:01 Uhr schrieb Paul Eggert : > On 2023-12-01 10:40, Bruno Haible wrote: > > > Indeed, this sentence appears to forbid ((char *) NULL) + something. > > Yes. However, Gnulib code can still use ((char *) NULL) + something) > because the Gnulib portability guidelines allow

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 19:42 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > By 6.5.6 "Additive Operators": > > > > (2) "... one operator shall be a pointer to a complete object type..." > > > > NULL, which is a null pointer con

Re: undefined-behavior obstack.c:139

By 6.5.6 "Additive Operators": (2) "... one operator shall be a pointer to a complete object type..." NULL, which is a null pointer constant, is not necessarily a pointer to a complete object type. (9) "... If the pointer operand and the result do not point to elements of the same array object

Re: new module 'jit/cache'

I forgot to actually make use of the patched part in the test case; here is the full patch. Please excuse the mess. Am Mo., 27. Nov. 2023 um 18:36 Uhr schrieb Marc Nieper-Wißkirchen < marc.nieper+...@gmail.com>: > Am Mo., 27. Nov. 2023 um 17:27 Uhr schrieb Marc Nieper-W

Re: new module 'jit/cache'

Am Mo., 27. Nov. 2023 um 17:27 Uhr schrieb Marc Nieper-Wißkirchen < marc.nieper+...@gmail.com>: [...] > For the moment, I expect >> - a SIGSEGV on powerpc*-aix, powerpc64-linux, ia64, hppa, and hppa64 >> due to the structure of function pointers, see >> >

[PATCH] stack: Fix documentation in header file.

Nieper-Wißkirchen + + stack: Fix documentation in header file. + * lib/stack.h: Correct documentation on `stack_current_base'. + 2023-11-27 Marc Nieper-Wißkirchen jit/cache-tests: Fix include guard. diff --git a/lib/stack.h b/lib/stack.h index dbd6812bc8..91b1944455 100644

[PATCH] jit/cache-tests: Fix include guard.

+1,8 @@ +2023-11-27 Marc Nieper-Wißkirchen + + jit/cache-tests: Fix include guard. + * tests/jit/test-cache.c (main): Extend range of include guard. + 2023-11-25 Marc Nieper-Wißkirchen jit/cache-tests: New module. diff --git a/tests/jit/test-cache.c b/tests/jit/test

Re: new module 'jit/cache'

Am Sa., 25. Nov. 2023 um 21:19 Uhr schrieb Bruno Haible : > Hello Marc, > > > Here is my attempt at a simple unit test for your new cache module. > > > > I have tested it on an x86 box (where the instruction cache is always in > > sync) and on an Armv8 Raspberry, both running GNU/Linux.

Re: new module 'jit/cache'

geLog | 9 + m4/valgrind-helper.m4 | 3 +- modules/jit/cache-tests | 20 +++ tests/jit/test-cache.c | 77 + 4 files changed, 108 insertions(+), 1 deletion(-) create mode 100644 modules/jit/cache-tests create mode 100644 tests/jit/test-cache.c diff --git a/ChangeL

Re: test environments

Hi Bruno, Thanks for making your module available. I have acquired a Raspberry Pi with an ARMv8, so as soon as my time permits, I should be able to do some testing. Marc Am Mo., 13. Nov. 2023 um 00:10 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > I only have access

Re: Provide a module for `clear_cache'

Hello Bruno, Am Mo., 6. Nov. 2023 um 19:33 Uhr schrieb Bruno Haible : [...] I can provide such a thing easily. In fact, I have it already sitting > around on my disk since 2021 :-) > This is great! > > GNU > > lightning currently calls libgcc's `__clear_cache' directly ([1]), but > this > >

Provide a module for `clear_cache'

The idea is to offer the builtin procedure __builtin__clear_cache (void *begin, void *end), which is provided at least by gcc and clang, in a portable manner. From the documentation of gcc's version: "This function is used to flush the processor’s instruction cache for the region of memory

Re: How to fix code blocks?

Happy new year, Bruno! Yes, sorry, wrong list! :) Marc Am Mo., 2. Jan. 2023 um 15:42 Uhr schrieb Bruno Haible : > > Hi Marc, > > > For purposes of dynamically calling code, I need the following layout > > of the assembled code: > > > > 0x00: 16-byte header > > 0x10: entry point #1 > > 0x20:

How to fix code blocks?

For purposes of dynamically calling code, I need the following layout of the assembled code: 0x00: 16-byte header 0x10: entry point #1 0x20: entry point #2 I want to use the new align/skip instructions for this. My code generator currently looks like this: align (16) header:

[PATCH] hamt: fix technically undefined behavior

rtions(+) diff --git a/ChangeLog b/ChangeLog index ccf4acd03..0d04cb70e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2022-08-12 Marc Nieper-Wißkirchen + + hamt: fix technically undefined behavior + Bug reported by Bruno Haible in + <https://lists.gnu.org/r/bug-gnuli

Re: undefined behaviour in hamt.c

Hi Bruno, thanks for exhibiting this. The complaint by the UB sanitizer is correct. Although the code won't use the 64-bit value shifted by 65, it is technically UB. When I wrote the code, I erroneously assumed that it would not be UB, but that the result of the shift would be

Re: Module idx

Bruno, Paul, thank you for your responses. So for a universal solution, one would have to teach first the i18n toolchain how to interpret general PRIxxx macros. Am Mi., 13. Apr. 2022 um 09:05 Uhr schrieb Paul Eggert : > > On 4/12/22 02:12, Marc Nieper-Wißkirchen wrote: > > I am w

Module idx

I am wondering how to print (using printf) values of type idx_t reliably without assuming that idx_t == ptrdiff_t and without conversion to uintptr_t. Would it make sense to add PRIxxx and SCNxxx macros (as those found in inttypes.h) to idx.h? Thanks, Marc

Re: and C++

Am Sa., 8. Jan. 2022 um 11:51 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > I submitted a patch. An email will follow. > > Ah, you already pushed it. Good! My workflow is not optimized yet. Pushing and sending out the email with the patch has to happen in two steps.

[PATCH 1/1] c-stack: Adapt header file for use in C++ applications.

* lib/c-stack.h: Add extern "C" block. --- ChangeLog | 5 + lib/c-stack.h | 8 2 files changed, 13 insertions(+) diff --git a/ChangeLog b/ChangeLog index ad525f531..64d70fd41 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2022-01-08 Marc Nieper-Wißkirchen +

[PATCH 1/1] version-etc: Adapt header file for use in C++ applications.

* lib/version-etc.h: Add extern "C" block. --- ChangeLog | 5 + lib/version-etc.h | 9 + 2 files changed, 14 insertions(+) diff --git a/ChangeLog b/ChangeLog index 60ca624f1..ad525f531 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2022-01-08 Marc Nieper-

Re: and C++

Am Fr., 7. Jan. 2022 um 21:54 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > I just noticed that doesn't include extern "C" guards > > so that inclusion in a C++ source file becomes easier (see 4.2 in the > > Gnulib manual). > > P

and C++

I just noticed that doesn't include extern "C" guards so that inclusion in a C++ source file becomes easier (see 4.2 in the Gnulib manual). I don't know what the general policy is, but including in a C++ makes sense to me and could be made easier. Marc PS I haven't systematically checked

Re: Bytewise u??_conv_from_encoding

Am Mi., 5. Jan. 2022 um 21:59 Uhr schrieb Bruno Haible : > > Hello Marc, > [...] > > If I understand your classification correctly, I meant something more > > like (E) than (D), I think. As an interface, I would propose would be > > something along the following lines: > > > > decoder_t d =

Re: Stack module and -Wsign-compare

Thank you, Paul. My local tests also show that it behaves better now. Am Mi., 5. Jan. 2022 um 20:54 Uhr schrieb Paul Eggert : > > On 1/5/22 10:00, Bruno Haible wrote: > > Another possible fix would be to change > >size_t size; > > to > >idx_t size; > > in the struct. > > Yes, that fits

Stack module and -Wsign-compare

Commit 3dc36216f168f4e752b648b19d85eab32a037827 by Paul Eggert introduced a regression in the stack module. If "stack.h" is included by client code that is supposed to be compiled with "-Wsign-compare", the compiler will complain about the comparison on line 121. There wasn't a problem before

Re: [striconveh] Error handling and Unicode replacement character

Dear Bruno, thank you for responding so quickly and for this addition! Marc Am Sa., 1. Jan. 2022 um 19:55 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote on 2021-12-30: > > The striconveh module and related modules offer an error handler > > argument. The curre

Re: Bytewise u??_conv_from_encoding

Hi Bruno, thanks for your insights, valuable as always. Am Sa., 1. Jan. 2022 um 13:57 Uhr schrieb Bruno Haible : > > Hi Marc, > > > The demand to read a file (in local encoding) and to decode it > > incrementally seems a typical one. > > There are four ways to satisfy this demand. > > (A) Using

Bytewise u??_conv_from_encoding

The demand to read a file (in local encoding) and to decode it incrementally seems a typical one. With Gnulib, this can be done using the mbfile module to read in the multibytes byte-by-byte and then using the striconveh module to decode the multibytes in, say, UTF-8 or UTF-32. This, however,

[striconveh] Error handling and Unicode replacement character

The striconveh module and related modules offer an error handler argument. The current possible values are: iconveh_error iconveh_question_mark iconveh_escape_sequence The second option replaces any unconvertible character with a question mark "?". I would like to request to add a fourth

Re: Non-recursive Make and prefix-gnulib-mk

Thanks for the tips! It's working perfectly now. Marc Am Do., 16. Dez. 2021 um 18:08 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > Am I supposed to set ${gl_source_base_prefix} somewhere? > > No. gnulib-tool defines gl_source_base_prefix as appropr

Re: Non-recursive Make and prefix-gnulib-mk

based on bootstrap and I have set source_base (and tests_base) in bootstrap.conf. Thanks, Marc Am Mi., 15. Dez. 2021 um 22:43 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > I'm using build-aux/prefix-gnulib-mk to rewrite the Gnulib Makefile > > fragment so that it

Non-recursive Make and prefix-gnulib-mk

Hi, I'm using build-aux/prefix-gnulib-mk to rewrite the Gnulib Makefile fragment so that it can be included by a Makefile in a top-level directory. What I haven't managed to get working, though, is renaming the Gnulib lib/ directory at the same time (by setting $source_base in bootstrap.conf).

Re: Signaling NaNs

Hi Bruno, thanks for replying so quickly! My intention is neither to feed the signaling NaN into floating-point operations nor to cause it an exception to be raised. What I really want to do is to model a type whose value is either a floating-point number (including infinities and the NaNs

Signaling NaNs

Hi, I have been searching through the list of modules but haven't been able to find it: Does Gnulib offer a way to store a signaling NaN in a memory location (if supported by the platform) and some way to check a memory location whether it contains a signaling NaN? The forthcoming C2x standard

Inline warnings in gl_xlist.h

When compiling my code with "-Winline", I suddenly get a warning from calling gl_list_add_last: "Call is unlikely and code size would grow." Is there a way to suppress this warning using Gnulib or can the inline functions of gl_xlist.h be implemented in a way so that this warning cannot show up?

Re: Module suggestion: timeout

, ...). Am Fr., 30. Apr. 2021 um 11:43 Uhr schrieb Simon Josefsson < si...@josefsson.org>: > Marc Nieper-Wißkirchen writes: > > > Moreover, use cases for a baked-in timeout are not restricted to tests. > For > > example, I may want to restrict the build time of certain c

Re: Module suggestion: timeout

Dear Bruno, dear Simon, thank you for your replies. I understand that valgrind-tests and the proposed "timeout-tests" solution are not completely equivalent. Nevertheless, I still think that some timeout functionality provided by Gnulib would be useful. Bruno's solution ** #if HAVE_DECL_ALARM

Module suggestion

Gnulib contains a module named valgrind that allows the easy use of Valgrind for tests whenever it is supported by the build system. I would suggest to add a similar module named timeout that sets the variable TIMEOUT with suitable defaults whenever the GNU coreutils timeout program (or an

Fwd: guile-devel Digest, Vol 221, Issue 18

Hi! In Guile's digest I noticed a comment about replacing libltdl (see below) with the standard `dlopen' interface and providing a shim for systems not supporting it directly. Do Guile's observations apply in general? Would it make sense for the Gnulib project to provide such a shimmed version

Re: Autogenerated header files not included in .gitignore

ehavior to the other but that, in principle, a developer can decide to switch to in-tree builds by touching such a file locally. Am Fr., 9. Apr. 2021 um 13:16 Uhr schrieb Marc Nieper-Wißkirchen < marc.nieper+...@gmail.com>: > I have been experimenting a bit with building in a dedicated build

Re: Autogenerated header files not included in .gitignore

-osf.h lib/iconv_open-solaris.h lib/iconv_open-zos.h Thanks, Marc Am Sa., 3. Apr. 2021 um 12:22 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > Would it do much harm if ".gitignore" included all built files even for > > developers that work

Re: Modules xsize and idx

Hi Bruno, thanks for replying so quickly. Let's assume I have a procedure void *foo_create (size_t n) { void *foo = malloc (a + n * b); if (foo == NULL) ...; ... return foo; } I want 'foo_create' to handle possible overflows. To me, it seems that should use the xsize module for this

Modules xsize and idx

What is the relationship between these two modules? Both try to minimize subtle bugs due to overflow. However, both approaches cannot be easily combined as xsize expects unsigned integers while idx is a signed one. What is the suggested use of these modules for new code? Thanks, Marc

Re: gl_list API

Am Di., 6. Apr. 2021 um 23:04 Uhr schrieb Bruno Haible : > > > But when designing a general utility, for all kinds of programs to use, > > > it is inappropriate to say "storing null elements is not useful". > > > > I'm afraid we'll have to disagree here. > > In some of my uses of the gl_list

Re: Type-safe typecasts

, gl_list_node_t *node_ptr) { void *e; return gl_list_iterator_next (iter, , node_ptr) ? e : NULL; } to the global API (modulo a better name for the procedure). Am Di., 6. Apr. 2021 um 21:20 Uhr schrieb Paul Eggert : > On 4/6/21 12:13 PM, Marc Nieper-Wißkirchen wrote: > > gl_list_iter

Re: New function xpalloc in module xalloc

Am Di., 6. Apr. 2021 um 21:05 Uhr schrieb Paul Eggert : > On 4/5/21 11:48 PM, Marc Nieper-Wißkirchen wrote: > > SIZE_MAX < (uintmax_t) nbytes > > Eeuuw! That's a cure worse than the disease. Among other things, there > is no guarantee that PTRDIFF_MAX <= UINTMAX_MAX so in

Re: Type-safe typecasts

Hi Paul, thanks! By the way, the snippet you gave is not portable C code, as it assumes > that 'void *' and 'struct foo *' have the same machine representation. > This is not necessarily true on (admittedly now-rare) machines that have > different flavors of pointers. I suspect the main problem

Type-safe typecasts

Hi, I have been wondering whether it makes sense to add a small utility trying to make typecasts in C as type-safe as possible. The problem is that typecasts are sometimes unavoidable. For an example, let's take a look at the following snippet using Gnulib's xlist module: struct foo { int

Re: New function xpalloc in module xalloc

Hi Paul, Am Di., 6. Apr. 2021 um 05:19 Uhr schrieb Paul Eggert : > On 4/3/21 11:17 PM, Marc Nieper-Wißkirchen wrote: > > Does the comparison make any sense, by the way? > > Yes, although it's needed only on unusual (and these days perhaps > theoretical?) platforms where SIZE

[PATCH 1/1] hamt: Fix coding errors.

From: Marc Nieper-Wißkirchen Reported by Bruno Haible in <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00047.html> after a Coverity run. * lib/hamt.c (bucket_do_while, hamt_iterator): Add missing derefencing operator and silence a bogus warning on uninitialized variables. *

Re: [PATCH] hamt: New module.

Hi Bruno, Am Mo., 5. Apr. 2021 um 15:02 Uhr schrieb Bruno Haible : > Hi Marc, > > > * tests/test-hamt.c: New file. > > Can you please have a quick look whether these Coverity findings (from our > weekly Coverity run) are relevant? > Coverity seems to be a good tool. I haven't yet tested GCC's

Re: Node to first or last element of a sequential list in module list/xlist

Hi Bruno, Am Mo., 5. Apr. 2021 um 04:45 Uhr schrieb Bruno Haible : > [Adding back bug-gnulib in CC.] > Thanks! > > Is there a fundamental reason why a list walking algorithm that both > > inserts and removes items is not possible with an arbitrary Gnulib list > > container? Obviously, the

[PATCH 1/1] hamt: Document the module in the Gnulib manual.

From: Marc Nieper-Wißkirchen Suggested by Bruno Haible in <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00026.html>. * doc/containers.texi: Add a subsection to section 15.11 Container data types. * lib/hamt.h: Improve documentation on how Hamt_entry is supposed to b

Re: New function xpalloc in module xalloc

it explicit. Am So., 4. Apr. 2021 um 08:24 Uhr schrieb Jeffrey Walton : > On Sun, Apr 4, 2021 at 2:17 AM Marc Nieper-Wißkirchen > wrote: > > > > GCC prints the following warning when compiling the new code: > > > > lib/xmalloc.c: In function 'xpalloc': >

New function xpalloc in module xalloc

GCC prints the following warning when compiling the new code: lib/xmalloc.c: In function 'xpalloc': lib/xmalloc.c:132:64: warning: comparison of integer expressions of different signedness: 'long unsigned int' and 'idx_t' {aka 'long int'} [-Wsign-compare] 132 | = ((INT_MULTIPLY_WRAPV (n,

Re: [PATCH] hamt: New module.

Hi Bruno, thank you very much for all the helpful feedback. I have incorporated your suggestions, and you can find an updated diff below. Thanks, Marc diff --git a/doc/containers.texi b/doc/containers.texi index 15c915b93..9bc1ae43d 100644 --- a/doc/containers.texi +++ b/doc/containers.texi @@

Re: [PATCH] hamt: New module.

Hi Bruno, what do you think of the attempt attached below? Thanks, Marc diff --git a/doc/containers.texi b/doc/containers.texi index 15c915b93..35caf200c 100644 --- a/doc/containers.texi +++ b/doc/containers.texi @@ -35,6 +35,9 @@ log Gnulib provides several generic container data types.

Re: Node to first or last element of a sequential list in module list/xlist

Hi Bruno, thank you very much! Am Sa., 3. Apr. 2021 um 18:28 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > For example, given a list of fruits, insert "pear" after each "apple" and > > "peach" before each "apple".

Re: Node to first or last element of a sequential list in module list/xlist

Am Sa., 3. Apr. 2021 um 12:14 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > > > > I don't understand. You want to use a list_node_t while adding > nodes to > > > > > the list? This is invalid, since the comments in gl_list.h say: > &

Re: Autogenerated header files not included in .gitignore

Hi Bruno, Am Sa., 3. Apr. 2021 um 12:05 Uhr schrieb Bruno Haible : > Hi Marc, > > > If Gnulib is going to be extended to support the second option as well > > That's what I'm suggesting, because the second way to manage files appears > to be the majority one. > > > I am not yet sure how. The

Re: Node to first or last element of a sequential list in module list/xlist

Am Sa., 3. Apr. 2021 um 11:49 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > > I don't understand. You want to use a list_node_t while adding nodes to > > > the list? This is invalid, since the comments in gl_list.h say: > > > > > &

[PATCH] hamt: New module.

From: Marc Nieper-Wißkirchen This module provides (persistent) hash array mapped tries. * MODULES.html.sh: Add hamt. * lib/hamt.c: New file. * lib/hamt.h: New file. * modules/hamt: New file. * modules/hamt-tests: New file. * tests/test-hamt.c: New file. --- ChangeLog | 11

Re: Non-opaque hamt type?

!= new_hamt" the element has been inserted and has now to eventually free "new_hamt" besides "old_hamt". After I have rebased my code to HEAD, I will commit the new module to Gnulib. Thank you for your patience. Marc Am So., 18. Okt. 2020 um 20:11 Uhr schrieb Marc Niepe

Re: Node to first or last element of a sequential list in module list/xlist

Hi, Am Sa., 3. Apr. 2021 um 00:49 Uhr schrieb Bruno Haible : > This is useful if the list has to be traversed while nodes are added > > because an iterator cannot be used here. > > I don't understand. You want to use a list_node_t while adding nodes to > the list? This is invalid, since the

Re: Autogenerated header files not included in .gitignore

Hi Bruno, thank you very much for your prompt reply. Am Sa., 3. Apr. 2021 um 01:00 Uhr schrieb Bruno Haible : As far as I know, there are two practices regarding .gitignore management: > > * Some developers want a very clean source directory at all times. > They always to VPATH builds.

Autogenerated header files not included in .gitignore

A number of autogenerated header files are not added to ".gitignore" in "$source_base". For example, in a current project of mine, $ git status shows lib/alloca.h lib/fcntl.h lib/inttypes.h lib/langinfo.h lib/limits.h lib/locale.h lib/signal.h lib/stdio.h lib/stdlib.h lib/string.h lib/sys/

Node to first or last element of a sequential list in module list/xlist

Hi! At the moment, there does not seem to be an easy way to retrieve the node of the first or the last element in a list. This is useful if the list has to be traversed while nodes are added because an iterator cannot be used here. What is currently possible is to use get_first/set_first (and

Re: Non-opaque hamt type?

Okay, if you find the latter protocol better anyway, I will switch to this protocol, and hamts will be stack-allocated (just two words) and passed by value. Thanks, Marc Am So., 18. Okt. 2020 um 19:58 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > The exist

Re: Non-opaque hamt type?

Am So., 18. Okt. 2020 um 16:39 Uhr schrieb Bruno Haible : > > Hi Marc, > > > At the moment, the header file exposes an opaque struct Hamt and > > communication with the code happens through (stack-allocated) pointers > > to a Hamt. In the implementation, however, each Hamt just consists of > > two

Re: Non-opaque hamt type?

One final issue (I hope): At the moment, the header file exposes an opaque struct Hamt and communication with the code happens through (stack-allocated) pointers to a Hamt. In the implementation, however, each Hamt just consists of two pointers (a pointer to a function table and a pointer to the

Re: Draft #3 (with iterators)

compilers. * Implement purely non-pure hamts to replace ordinary hash tables. * Add _nx versions of the procedures that won't call xalloc_die. Many thanks to Bruno for his support, guidance and his great suggestions. Marc Am So., 11. Okt. 2020 um 19:32 Uhr schrieb Marc Nieper-Wißkirchen : > >

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am So., 11. Okt. 2020 um 10:20 Uhr schrieb Marc Nieper-Wißkirchen : > > Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible : [...] > > * hamt_lookup: If the caller is allowed to modify the payload stored in the > > returned entry, this function should re

Re: terminology

Am So., 11. Okt. 2020 um 16:14 Uhr schrieb Bruno Haible : > > Hi Marc, > > > I have attached an improved version of the HAMT module to this email. > > How about terminology: "delete" vs. "remove"? > In this sense, 'hamt_delete' is triggering the wrong associations. > How about renaming

Re: HAMT iterators

Am So., 11. Okt. 2020 um 12:29 Uhr schrieb Bruno Haible : > The recursion across hamt_do_while / entry_do_while / subtrie_do_while / > bucket_do_while builds up a stack whose essential contents is a set of > indices, each at most 5 bits large, with a total of SIZE_WIDTH bits. > In other words,

Re: HAMT iterator

Am So., 11. Okt. 2020 um 14:04 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > > > /* Return an independent copy of ITER that is initially in the same > > > >state. */ > > > > extern Hamt_iterator *hamt_iterator_copy (Hamt_iterato

Re: HAMT iterator

Am So., 11. Okt. 2020 um 14:14 Uhr schrieb Bruno Haible : [...] > > > > /* Return an independent copy of ITER that is initially in the same > > > >state. */ > > > > extern Hamt_iterator *hamt_iterator_copy (Hamt_iterator *iter); > > > > > > Then a copy function is not needed, because the

Re: out-of-memory handling

Am So., 11. Okt. 2020 um 13:56 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > I am not so convinced of whether it makes sense to create a > > gl_set/gl_map frontend for this hamt implementation. > > Wikipedia [1] lists some advantages of HAMTs even

Re: HAMT iterator

Am So., 11. Okt. 2020 um 13:02 Uhr schrieb Bruno Haible : > > Hi Marc, > > > I am going to implement the following iterator API as well: > > > > /* An alternative interface to iterating through the entry of a hamt > >that does not make use of a higher-order function like > >hamt_do_while

Re: out-of-memory handling

Am So., 11. Okt. 2020 um 12:54 Uhr schrieb Bruno Haible : > > The bigger problem is that it mustn't make the code slower for the > > 99,9% of the use cases where there is either enough memory or > > calling xalloc_die is the only reasonable action. > > OK. When we add hamt as a possible

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

, Hamt_entry *const *elt_ptr); Am So., 11. Okt. 2020 um 10:20 Uhr schrieb Marc Nieper-Wißkirchen : > Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible : > >- Creating a closure in C (unlike Scheme or Lisp) is tedious >

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible : > > Hi Marc, > > Some comments: > > * GL_HAMT_THREAD_SAFE can be defined to 1 not only if > __STDC_VERSION__ >= 201112 && ! defined __STD_NO_ATOMICS__ > but also if > __GNUC__ + (__GNUC_MINOR >= 9) > 4 Fixed. > (see the other

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

/srfi-146/srfi-146.html Am Sa., 10. Okt. 2020 um 23:24 Uhr schrieb Marc Nieper-Wißkirchen : > > Am Sa., 10. Okt. 2020 um 20:19 Uhr schrieb Paul Eggert : > > > #if __STDC_VERSION__ < 201112 || defined __STD_NO_ATOMICS__ > > > > which is a cleaner way of writing

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am Sa., 10. Okt. 2020 um 20:19 Uhr schrieb Paul Eggert : > #if __STDC_VERSION__ < 201112 || defined __STD_NO_ATOMICS__ > > which is a cleaner way of writing the negative of the above test. These days > there should be no reason to check whether __STDC_VERSION__ is defined, > generally it's

[PATCH] stack: New module.

From: Marc Nieper-Wißkirchen * MODULES.html.sh: Add entry for the stack module. * modules/stack: New file. * modules/stack-tests: New file. * lib/stack.h: New file. * tests/test-stack.c: New file. --- ChangeLog | 9 +++ MODULES.html.sh | 1 + lib/stack.h | 165

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am Sa., 10. Okt. 2020 um 19:41 Uhr schrieb Bruno Haible : > > Hi Marc, > > > Is there a special Gnulib way (or Autoconf macro) for the following test: > > > > #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L && > > !defined (__STD_NO_ATOMICS__) > > > > I am asking because there may be

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

rstand _Atomic. Am Sa., 10. Okt. 2020 um 17:01 Uhr schrieb Marc Nieper-Wißkirchen : > > Am Sa., 10. Okt. 2020 um 16:54 Uhr schrieb Bruno Haible : > > > > Since you define GL_HAMT_THREAD_SAFE to either 0 or 1, you need > > to test it through > > #if GL_HAMT_THR

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am Sa., 10. Okt. 2020 um 16:54 Uhr schrieb Bruno Haible : > > Since you define GL_HAMT_THREAD_SAFE to either 0 or 1, you need > to test it through > #if GL_HAMT_THREAD_SAFE > not > #ifdef GL_HAMT_THREAD_SAFE > > Bruno Oh, yes... thanks!

Re: Unused parameter warnings

Am Sa., 10. Okt. 2020 um 16:39 Uhr schrieb Bruno Haible : > > Hi Marc, > > > I can ask for a better description of "pure" in the GCC manual. > > Yes, please. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97364

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Hi Bruno, Am Sa., 10. Okt. 2020 um 16:35 Uhr schrieb Bruno Haible : > It is exciting to see such a datastructure with various application domains > [1] > in Gnulib! I'm glad that you like the idea. > > I haven't read through it line by line; nevertheless a couple of comments: A few more

Re: stack module

Hi Bruno, Am Sa., 10. Okt. 2020 um 16:06 Uhr schrieb Bruno Haible : > > Hi Marc, > > > please see the attached patch for the new module. > > Very nice. Looks all good, except for some nit-picking in the comments: Thanks. > > > + Introspection: ELEMENT *base = stack_base (); > > I would

Re: Unused parameter warnings

ure" attribute so that the code is compilable with -Werror -Wall -Wextra. Am Sa., 10. Okt. 2020 um 15:50 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > > And a function that may invoke abort () does "affect observable state". > > > > This des

[New module] Persistent Hash Array Mapped Tries (HAMTs)

+1,812 @@ +/* (Persistent) hash array mapped tries. + Copyright (C) 2020 Free Software Foundation, Inc. + Written by Marc Nieper-Wißkirchen , 2020. + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published

Re: stack module

Dear Bruno, please see the attached patch for the new module. Thanks, Marc Am Mi., 7. Okt. 2020 um 11:01 Uhr schrieb Marc Nieper-Wißkirchen : > > Hi Bruno, > > I am finally finishing my work on the stack module. > > Am Do., 23. Juli 2020 um 12:36 Uhr sc

Re: stack module

Hi Bruno, I am finally finishing my work on the stack module. Am Do., 23. Juli 2020 um 12:36 Uhr schrieb Bruno Haible : [...] > This is perfectly acceptable for Gnulib. It has debuggability and type safety. > > You have precedent e.g. in lib/diffseq.h and lib/aligned-malloc.h. > > You can even

  1   2   >