On Sat, 14 Sep 2002, Bill Bogstad wrote:
> [list.c] makes some effort to allow the upper end of the allocated
> range (list->high) to increase beyond that specified when the array
> was originally created, but an incomplete effort to support a
> reduction in the low end (list->low).
Sorry I missed the original report of the bug in the LF_SPARSE case.
The incompleteness might be in the non-LF_SPARSE case, where we assume
that the list is always growing upwards (see below).
> Also, I am not sure what the flag LF_SPARSE means. In general, lists
> appear to always be sparsely allocated.
There are a few things that don't pass in the LF_SPARSE value, such as
the datasrc_list. In such cases, the first array element is always
allocated first, and growth must proceed in an upward direction one
element at a time. If the code skips around at all, it must use
LF_SPARSE.
Here's my proposed change to fix the bug in list.c. See if you like it.
..wayne..
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---
Index: list.c
--- list.c 25 May 2000 05:11:42 -0000 1.1
+++ list.c 24 Sep 2002 00:44:35 -0000
@@ -67,9 +67,11 @@
if (!node || num < node->low) {
node = (LISTNODE*)safemalloc(list->items_per_node*list->item_size
+ sizeof (LISTNODE) - 1);
- if (list->flags & LF_SPARSE)
- node->low = ((num - list->low) / list->items_per_node)
- * list->items_per_node + list->low;
+ if (list->flags & LF_SPARSE) {
+ int ofst = list->low % list->items_per_node;
+ node->low = ((num - ofst) / list->items_per_node)
+ * list->items_per_node + ofst;
+ }
else
node->low = num;
node->high = node->low + list->items_per_node - 1;
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
