SIZE_MAX could be defined as -1 promoted to an unsigned type, meaning that
the unsigned comparison would always yield false. Or am I missing something?
In any case, if the promotion is what is intended, 'nbytes' should be
probably replaced with '(size_t) nbytes' to silence the warning and to make
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':
> lib/xmalloc.c:132:64: warning: comparison of integer expressions of different
> signedness: 'long unsigned int' and 'idx_t' {a
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, ite
* lib/savedir.c (streamsavedir): Prefer idx_to size_t where
either will do. Simplify reallocation of entries.
Use xpalloc to reallocate name_space, to avoid some unlikely
integer overflows.
---
ChangeLog | 6 ++
lib/savedir.c | 25 +
2 files changed, 15 insertions
Avoid undefined and O(N**2) behavior in some very unlikely cases.
* lib/quotearg.c (quotearg_n_options): Document that N must
be less than MIN (INT_MAX, IDX_MAX), and add this to the
abort test; this also avoids a conditional branch.
Use xpalloc instead of xrealloc, to avoid O(N**2) behavior in
ver
On 4/2/21 8:32 AM, Paul Eggert wrote:
I can fix it by removing the divergence.
I did that by installing the attached, which causes xgetdomainname.c to
be a couple of #defines followed by "#include "xgethostname.c".
>From 635076e47c7a000a11b3c2d173d5ef047fcf9af2 Mon Sep 17 00:00:00 2001
From: P
Hi Marc,
> thank you very much for all the helpful feedback. I have incorporated your
> suggestions, and you can find an updated diff below.
This is definitely better.
> +Lookup of a (key, value) pair given the key is an O(1) operation,
I forgot to say "on average" here. (It's not worst-case O(
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
@@
Hi Marc,
> what do you think of the attempt attached below?
I believe that technical documentation of a feature should be written
to answer the questions in this order:
1. What is it? (Short summary)
2. When would I use it? (Use cases)
3. How do I use it?
4. Further details.
The idea is
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. They
Hi Marc,
> + hamt: New module.
> + 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-
Marc Nieper-Wißkirchen wrote:
> > Yes, some algorithms need a second, temporary list. Not all algorithms
> > can be written to use the original list, be efficient in O() terms, and
> > be implementation-independent.
>
> Speaking of this, this is not always non-trivial if the dispose function is
>
Paul Eggert wrote:
> * lib/xalloc.h: Include idx.h, for idx_t.
This causes a compilation error in a testdir:
In file included from ../../gltests/xalloc-die.c:21:0:
../../gltests/xalloc.h:24:17: fatal error: idx.h: No such file or directory
compilation terminated.
make[4]: *** [Makefile:3215: xall
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". This can be easily done through
> > gl_list_add_before/gl_list_ad
Marc Nieper-Wißkirchen wrote:
> For example, given a list of fruits, insert "pear" after each "apple" and
> "peach" before each "apple". This can be easily done through
> gl_list_add_before/gl_list_add_after/gl_list_next_node without using
> invalidated nodes.
Now I see what you mean. Quasi compan
Hi Marc,
> Secondly, after having given it some more thought, the alternative protocol
> (which we have called more robust) seems to be harder to understand because
> "p != e" could then mean two different things. So I will leave the original
> protocol in place, which is easy to comprehend: If "o
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:
> > > > >
> > > > > /* Type representing the posi
Marc Nieper-Wißkirchen wrote:
> Would it do much harm if ".gitignore" included all built files even for
> developers that work in a dedicated build tree?
The developers who are using the first approach will not like this.
Bruno
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 prob
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:
> > > >
> > > > /* Type representing the position of an element in the list, in a way
> > > > that
> > > > is
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 problem is that the same source tree would have to
> support both options to support b
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:
> > >
> > > /* Type representing the position of an element
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:
> >
> > /* Type representing the position of an element in the list, in a way
> > that
> > is more adapted to the list
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 +
MODULES.h
Please excuse the delay in finalizing the new module. I was distracted due
to the start of the semester in October last year and then forgot to finish
my work.
To summarize, I have finally come to the conclusion not to change the API
as theorized in this thread.
First of all, the benefits of maki
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 comme
26 matches
Mail list logo
