nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/utils/tree234.c

1639 lines
53 KiB
C
Raw Normal View History

2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
/*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* tree234.c: reasonably generic counted 2-3-4 tree routines.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* This file is copyright 1999-2001 Simon Tatham.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
* conditions:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL SIMON TATHAM BE LIABLE FOR
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
* CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
#include <assert.h>
Make memory management uniform: _everything_ now goes through the smalloc() macros and thence to the safemalloc() functions in misc.c. This should allow me to plug in a debugging allocator and track memory leaks and segfaults and things. [originally from svn r818]
2000-12-12 10:33:13 +00:00
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
#include "defs.h"
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
#include "tree234.h"
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
#include "puttymem.h"
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
#ifdef TEST
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
static int verbose = 0;
#define LOG(x) do \
{ \
if (verbose > 2) \
printf x; \
} while (0)
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
#else
Remove diagnostics and attempt to work around VC compiler bug :-( [originally from svn r1096]
2001-05-03 10:10:53 +00:00
#define LOG(x)
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
#endif
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
typedef struct node234_Tag node234;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
struct tree234_Tag {
node234 *root;
cmpfn234 cmp;
};
struct node234_Tag {
node234 *parent;
node234 *kids[4];
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int counts[4];
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
void *elems[3];
};
/*
* Create a 2-3-4 tree.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
tree234 *newtree234(cmpfn234 cmp)
{
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
tree234 *t = snew(tree234);
LOG(("created tree %p\n", t));
t->root = NULL;
t->cmp = cmp;
return t;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
/*
* Free a 2-3-4 tree (not including freeing the elements).
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
static void freenode234(node234 *n)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
if (!n)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
freenode234(n->kids[0]);
freenode234(n->kids[1]);
freenode234(n->kids[2]);
freenode234(n->kids[3]);
sfree(n);
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void freetree234(tree234 *t)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
freenode234(t->root);
sfree(t);
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
/*
* Internal function to count a node.
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
static int countnode234(node234 *n)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int count = 0;
int i;
countnode234() should politely return 0 when passed NULL. Was breaking delpos234(empty_tree, 0). [originally from svn r1054]
2001-04-16 21:24:38 +00:00
if (!n)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
for (i = 0; i < 4; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
count += n->counts[i];
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
for (i = 0; i < 3; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (n->elems[i])
count++;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return count;
}
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
/*
* Internal function to return the number of elements in a node.
*/
static int elements234(node234 *n)
{
int i;
for (i = 0; i < 3; i++)
if (!n->elems[i])
break;
return i;
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
/*
* Count the elements in a tree.
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
int count234(tree234 *t)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (t->root)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return countnode234(t->root);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return 0;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
/*
* Add an element e to a 2-3-4 tree t. Returns e on success, or if
* an existing element compares equal, returns that.
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
static void *add234_internal(tree234 *t, void *e, int index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
node234 *n, **np, *left, *right;
void *orig_e = e;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int c, lcount, rcount;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
LOG(("adding node %p to tree %p\n", e, t));
if (t->root == NULL) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
t->root = snew(node234);
t->root->elems[1] = t->root->elems[2] = NULL;
t->root->kids[0] = t->root->kids[1] = NULL;
t->root->kids[2] = t->root->kids[3] = NULL;
t->root->counts[0] = t->root->counts[1] = 0;
t->root->counts[2] = t->root->counts[3] = 0;
t->root->parent = NULL;
t->root->elems[0] = e;
LOG((" created root %p\n", t->root));
return orig_e;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Patch from Colin Watson intended to give a clean Unix compile with GCC 4. (Since we choose to compile with -Werror, this is particularly important.) I haven't yet checked that the resulting source actually compiles cleanly with GCC 4, hence not marking `gcc4-warnings' as fixed just yet. [originally from svn r7041]
2006-12-30 23:00:14 +00:00
n = NULL; /* placate gcc; will always be set below since t->root != NULL */
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
np = &t->root;
while (*np) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int childnum;
n = *np;
LOG((" node %p: %p/%d [%p] %p/%d [%p] %p/%d [%p] %p/%d\n",
n,
n->kids[0], n->counts[0], n->elems[0],
n->kids[1], n->counts[1], n->elems[1],
n->kids[2], n->counts[2], n->elems[2],
n->kids[3], n->counts[3]));
if (index >= 0) {
if (!n->kids[0]) {
/*
* Leaf node. We want to insert at kid position
* equal to the index:
*
* 0 A 1 B 2 C 3
*/
childnum = index;
} else {
/*
* Internal node. We always descend through it (add
* always starts at the bottom, never in the
* middle).
*/
do { /* this is a do ... while (0) to allow `break' */
if (index <= n->counts[0]) {
childnum = 0;
break;
}
index -= n->counts[0] + 1;
if (index <= n->counts[1]) {
childnum = 1;
break;
}
index -= n->counts[1] + 1;
if (index <= n->counts[2]) {
childnum = 2;
break;
}
index -= n->counts[2] + 1;
if (index <= n->counts[3]) {
childnum = 3;
break;
}
return NULL; /* error: index out of range */
} while (0);
}
} else {
if ((c = t->cmp(e, n->elems[0])) < 0)
childnum = 0;
else if (c == 0)
return n->elems[0]; /* already exists */
else if (n->elems[1] == NULL
|| (c = t->cmp(e, n->elems[1])) < 0) childnum = 1;
else if (c == 0)
return n->elems[1]; /* already exists */
else if (n->elems[2] == NULL
|| (c = t->cmp(e, n->elems[2])) < 0) childnum = 2;
else if (c == 0)
return n->elems[2]; /* already exists */
else
childnum = 3;
}
np = &n->kids[childnum];
LOG((" moving to child %d (%p)\n", childnum, *np));
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
/*
* We need to insert the new element in n at position np.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
left = NULL;
lcount = 0;
right = NULL;
rcount = 0;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
while (n) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
LOG((" at %p: %p/%d [%p] %p/%d [%p] %p/%d [%p] %p/%d\n",
n,
n->kids[0], n->counts[0], n->elems[0],
n->kids[1], n->counts[1], n->elems[1],
n->kids[2], n->counts[2], n->elems[2],
n->kids[3], n->counts[3]));
LOG((" need to insert %p/%d [%p] %p/%d at position %d\n",
left, lcount, e, right, rcount, (int)(np - n->kids)));
if (n->elems[1] == NULL) {
/*
* Insert in a 2-node; simple.
*/
if (np == &n->kids[0]) {
LOG((" inserting on left of 2-node\n"));
n->kids[2] = n->kids[1];
n->counts[2] = n->counts[1];
n->elems[1] = n->elems[0];
n->kids[1] = right;
n->counts[1] = rcount;
n->elems[0] = e;
n->kids[0] = left;
n->counts[0] = lcount;
} else { /* np == &n->kids[1] */
LOG((" inserting on right of 2-node\n"));
n->kids[2] = right;
n->counts[2] = rcount;
n->elems[1] = e;
n->kids[1] = left;
n->counts[1] = lcount;
}
if (n->kids[0])
n->kids[0]->parent = n;
if (n->kids[1])
n->kids[1]->parent = n;
if (n->kids[2])
n->kids[2]->parent = n;
LOG((" done\n"));
break;
} else if (n->elems[2] == NULL) {
/*
* Insert in a 3-node; simple.
*/
if (np == &n->kids[0]) {
LOG((" inserting on left of 3-node\n"));
n->kids[3] = n->kids[2];
n->counts[3] = n->counts[2];
n->elems[2] = n->elems[1];
n->kids[2] = n->kids[1];
n->counts[2] = n->counts[1];
n->elems[1] = n->elems[0];
n->kids[1] = right;
n->counts[1] = rcount;
n->elems[0] = e;
n->kids[0] = left;
n->counts[0] = lcount;
} else if (np == &n->kids[1]) {
LOG((" inserting in middle of 3-node\n"));
n->kids[3] = n->kids[2];
n->counts[3] = n->counts[2];
n->elems[2] = n->elems[1];
n->kids[2] = right;
n->counts[2] = rcount;
n->elems[1] = e;
n->kids[1] = left;
n->counts[1] = lcount;
} else { /* np == &n->kids[2] */
LOG((" inserting on right of 3-node\n"));
n->kids[3] = right;
n->counts[3] = rcount;
n->elems[2] = e;
n->kids[2] = left;
n->counts[2] = lcount;
}
if (n->kids[0])
n->kids[0]->parent = n;
if (n->kids[1])
n->kids[1]->parent = n;
if (n->kids[2])
n->kids[2]->parent = n;
if (n->kids[3])
n->kids[3]->parent = n;
LOG((" done\n"));
break;
} else {
node234 *m = snew(node234);
m->parent = n->parent;
LOG((" splitting a 4-node; created new node %p\n", m));
/*
* Insert in a 4-node; split into a 2-node and a
* 3-node, and move focus up a level.
*
* I don't think it matters which way round we put the
* 2 and the 3. For simplicity, we'll put the 3 first
* always.
*/
if (np == &n->kids[0]) {
m->kids[0] = left;
m->counts[0] = lcount;
m->elems[0] = e;
m->kids[1] = right;
m->counts[1] = rcount;
m->elems[1] = n->elems[0];
m->kids[2] = n->kids[1];
m->counts[2] = n->counts[1];
e = n->elems[1];
n->kids[0] = n->kids[2];
n->counts[0] = n->counts[2];
n->elems[0] = n->elems[2];
n->kids[1] = n->kids[3];
n->counts[1] = n->counts[3];
} else if (np == &n->kids[1]) {
m->kids[0] = n->kids[0];
m->counts[0] = n->counts[0];
m->elems[0] = n->elems[0];
m->kids[1] = left;
m->counts[1] = lcount;
m->elems[1] = e;
m->kids[2] = right;
m->counts[2] = rcount;
e = n->elems[1];
n->kids[0] = n->kids[2];
n->counts[0] = n->counts[2];
n->elems[0] = n->elems[2];
n->kids[1] = n->kids[3];
n->counts[1] = n->counts[3];
} else if (np == &n->kids[2]) {
m->kids[0] = n->kids[0];
m->counts[0] = n->counts[0];
m->elems[0] = n->elems[0];
m->kids[1] = n->kids[1];
m->counts[1] = n->counts[1];
m->elems[1] = n->elems[1];
m->kids[2] = left;
m->counts[2] = lcount;
/* e = e; */
n->kids[0] = right;
n->counts[0] = rcount;
n->elems[0] = n->elems[2];
n->kids[1] = n->kids[3];
n->counts[1] = n->counts[3];
} else { /* np == &n->kids[3] */
m->kids[0] = n->kids[0];
m->counts[0] = n->counts[0];
m->elems[0] = n->elems[0];
m->kids[1] = n->kids[1];
m->counts[1] = n->counts[1];
m->elems[1] = n->elems[1];
m->kids[2] = n->kids[2];
m->counts[2] = n->counts[2];
n->kids[0] = left;
n->counts[0] = lcount;
n->elems[0] = e;
n->kids[1] = right;
n->counts[1] = rcount;
e = n->elems[2];
}
m->kids[3] = n->kids[3] = n->kids[2] = NULL;
m->counts[3] = n->counts[3] = n->counts[2] = 0;
m->elems[2] = n->elems[2] = n->elems[1] = NULL;
if (m->kids[0])
m->kids[0]->parent = m;
if (m->kids[1])
m->kids[1]->parent = m;
if (m->kids[2])
m->kids[2]->parent = m;
if (n->kids[0])
n->kids[0]->parent = n;
if (n->kids[1])
n->kids[1]->parent = n;
LOG((" left (%p): %p/%d [%p] %p/%d [%p] %p/%d\n", m,
m->kids[0], m->counts[0], m->elems[0],
m->kids[1], m->counts[1], m->elems[1],
m->kids[2], m->counts[2]));
LOG((" right (%p): %p/%d [%p] %p/%d\n", n,
n->kids[0], n->counts[0], n->elems[0],
n->kids[1], n->counts[1]));
left = m;
lcount = countnode234(left);
right = n;
rcount = countnode234(right);
}
if (n->parent)
np = (n->parent->kids[0] == n ? &n->parent->kids[0] :
n->parent->kids[1] == n ? &n->parent->kids[1] :
n->parent->kids[2] == n ? &n->parent->kids[2] :
&n->parent->kids[3]);
n = n->parent;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
/*
* If we've come out of here by `break', n will still be
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* non-NULL and all we need to do is go back up the tree
* updating counts. If we've come here because n is NULL, we
* need to create a new root for the tree because the old one
* has just split into two. */
if (n) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (n->parent) {
int count = countnode234(n);
int childnum;
childnum = (n->parent->kids[0] == n ? 0 :
n->parent->kids[1] == n ? 1 :
n->parent->kids[2] == n ? 2 : 3);
n->parent->counts[childnum] = count;
n = n->parent;
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
LOG((" root is overloaded, split into two\n"));
t->root = snew(node234);
t->root->kids[0] = left;
t->root->counts[0] = lcount;
t->root->elems[0] = e;
t->root->kids[1] = right;
t->root->counts[1] = rcount;
t->root->elems[1] = NULL;
t->root->kids[2] = NULL;
t->root->counts[2] = 0;
t->root->elems[2] = NULL;
t->root->kids[3] = NULL;
t->root->counts[3] = 0;
t->root->parent = NULL;
if (t->root->kids[0])
t->root->kids[0]->parent = t->root;
if (t->root->kids[1])
t->root->kids[1]->parent = t->root;
LOG((" new root is %p/%d [%p] %p/%d\n",
t->root->kids[0], t->root->counts[0],
t->root->elems[0], t->root->kids[1], t->root->counts[1]));
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
return orig_e;
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *add234(tree234 *t, void *e)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!t->cmp) /* tree is unsorted */
return NULL;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return add234_internal(t, e, -1);
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *addpos234(tree234 *t, void *e, int index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (index < 0 || /* index out of range */
t->cmp) /* tree is sorted */
return NULL; /* return failure */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return add234_internal(t, e, index); /* this checks the upper bound */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
/*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* Look up the element at a given numeric index in a 2-3-4 tree.
* Returns NULL if the index is out of range.
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *index234(tree234 *t, int index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
node234 *n;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (!t->root)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL; /* tree is empty */
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (index < 0 || index >= countnode234(t->root))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL; /* out of range */
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
n = t->root;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
while (n) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (index < n->counts[0])
n = n->kids[0];
else if (index -= n->counts[0] + 1, index < 0)
return n->elems[0];
else if (index < n->counts[1])
n = n->kids[1];
else if (index -= n->counts[1] + 1, index < 0)
return n->elems[1];
else if (index < n->counts[2])
n = n->kids[2];
else if (index -= n->counts[2] + 1, index < 0)
return n->elems[2];
else
n = n->kids[3];
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
/* We shouldn't ever get here. I wonder how we did. */
return NULL;
}
/*
* Find an element e in a sorted 2-3-4 tree t. Returns NULL if not
* found. e is always passed as the first argument to cmp, so cmp
* can be an asymmetric function if desired. cmp can also be passed
* as NULL, in which case the compare function from the tree proper
* will be used.
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *findrelpos234(tree234 *t, void *e, cmpfn234 cmp,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
int relation, int *index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
search234_state ss;
int reldir = (relation == REL234_LT || relation == REL234_LE ? -1 :
relation == REL234_GT || relation == REL234_GE ? +1 : 0);
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool equal_permitted = (relation != REL234_LT && relation != REL234_GT);
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
void *toret;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
/* Only LT / GT relations are permitted with a null query element. */
assert(!(equal_permitted && !e));
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (cmp == NULL)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cmp = t->cmp;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
search234_start(&ss, t);
while (ss.element) {
int cmpret;
if (e) {
cmpret = cmp(e, ss.element);
} else {
cmpret = -reldir; /* invent a fixed compare result */
}
if (cmpret == 0) {
/*
* We've found an element that compares exactly equal to
* the query element.
*/
if (equal_permitted) {
/* If our search relation permits equality, we've
* finished already. */
if (index)
*index = ss.index;
return ss.element;
} else {
/* Otherwise, pretend this element was slightly too
* big/small, according to the direction of search. */
cmpret = reldir;
}
}
search234_step(&ss, cmpret);
}
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
/*
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
* No element compares equal to the one we were after, but
* ss.index indicates the index that element would have if it were
* inserted.
*
* So if our search relation is EQ, we must simply return failure.
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
*/
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
if (relation == REL234_EQ)
return NULL;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
/*
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
* Otherwise, we must do an index lookup for the previous index
* (if we're going left - LE or LT) or this index (if we're going
* right - GE or GT).
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
*/
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
if (relation == REL234_LT || relation == REL234_LE) {
ss.index--;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
/*
* We know the index of the element we want; just call index234
* to do the rest. This will return NULL if the index is out of
* bounds, which is exactly what we want.
*/
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
toret = index234(t, ss.index);
if (toret && index)
*index = ss.index;
return toret;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *find234(tree234 *t, void *e, cmpfn234 cmp)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return findrelpos234(t, e, cmp, REL234_EQ, NULL);
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *findrel234(tree234 *t, void *e, cmpfn234 cmp, int relation)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return findrelpos234(t, e, cmp, relation, NULL);
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *findpos234(tree234 *t, void *e, cmpfn234 cmp, int *index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return findrelpos234(t, e, cmp, REL234_EQ, index);
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
void search234_start(search234_state *state, tree234 *t)
{
state->_node = t->root;
state->_base = 0; /* index of first element in this node's subtree */
Fix a batch of typos in comments and docs.
2022-01-03 06:38:07 +00:00
state->_last = -1; /* indicate that this node is not previously visited */
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
search234_step(state, 0);
}
void search234_step(search234_state *state, int direction)
{
node234 *node = state->_node;
int i;
if (!node) {
state->element = NULL;
state->index = 0;
return;
}
if (state->_last != -1) {
/*
* We're already pointing at some element of a node, so we
* should restrict to the elements left or right of it,
* depending on the requested search direction.
*/
assert(direction);
assert(node);
Remove some redundant variables and assignments. This fixes a batch of clang-analyzer warnings of the form 'you declared / assigned this variable and then never use it'. It doesn't fix _all_ of them - some are there so that when I add code in the future _it_ can use the variable without me having to remember to start setting it - but these are the ones I thought it would make the code better instead of worse to fix.
2018-12-01 14:06:44 +00:00
if (direction > 0)
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
state->_lo = state->_last + 1;
Remove some redundant variables and assignments. This fixes a batch of clang-analyzer warnings of the form 'you declared / assigned this variable and then never use it'. It doesn't fix _all_ of them - some are there so that when I add code in the future _it_ can use the variable without me having to remember to start setting it - but these are the ones I thought it would make the code better instead of worse to fix.
2018-12-01 14:06:44 +00:00
else
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
state->_hi = state->_last - 1;
if (state->_lo > state->_hi) {
/*
* We've run out of elements in this node, i.e. we've
* narrowed to nothing but a child pointer. Descend to
* that child, and update _base to the leftmost index of
* its subtree.
*/
for (i = 0; i < state->_lo; i++)
state->_base += 1 + node->counts[i];
state->_node = node = node->kids[state->_lo];
state->_last = -1;
}
}
if (state->_last == -1) {
/*
* We've just entered a new node - either because of the above
* code, or because we were called from search234_start - and
* anything in that node is a viable answer.
*/
state->_lo = 0;
state->_hi = node ? elements234(node)-1 : 0;
}
/*
* Now we've got something we can return.
*/
if (!node) {
state->element = NULL;
state->index = state->_base;
} else {
state->_last = (state->_lo + state->_hi) / 2;
state->element = node->elems[state->_last];
state->index = state->_base + state->_last;
for (i = 0; i <= state->_last; i++)
state->index += node->counts[i];
}
}
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
/*
* Delete an element e in a 2-3-4 tree. Does not free the element,
* merely removes all links to it from the tree nodes.
*/
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
static void *delpos234_internal(tree234 *t, int index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
node234 *n;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
void *retval;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
int ei = -1;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
retval = 0;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
n = t->root;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
LOG(("deleting item %d from tree %p\n", index, t));
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
while (1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
while (n) {
int ki;
node234 *sub;
LOG(
(" node %p: %p/%d [%p] %p/%d [%p] %p/%d [%p] %p/%d index=%d\n",
n, n->kids[0], n->counts[0], n->elems[0], n->kids[1],
n->counts[1], n->elems[1], n->kids[2], n->counts[2],
n->elems[2], n->kids[3], n->counts[3], index));
if (index < n->counts[0]) {
ki = 0;
} else if (index -= n->counts[0] + 1, index < 0) {
ei = 0;
break;
} else if (index < n->counts[1]) {
ki = 1;
} else if (index -= n->counts[1] + 1, index < 0) {
ei = 1;
break;
} else if (index < n->counts[2]) {
ki = 2;
} else if (index -= n->counts[2] + 1, index < 0) {
ei = 2;
break;
} else {
ki = 3;
}
/*
* Recurse down to subtree ki. If it has only one element,
* we have to do some transformation to start with.
*/
LOG((" moving to subtree %d\n", ki));
sub = n->kids[ki];
if (!sub->elems[1]) {
LOG((" subtree has only one element!\n"));
if (ki > 0 && n->kids[ki - 1]->elems[1]) {
/*
* Case 3a, left-handed variant. Child ki has
* only one element, but child ki-1 has two or
* more. So we need to move a subtree from ki-1
* to ki.
*
* . C . . B .
* / \ -> / \
* [more] a A b B c d D e [more] a A b c C d D e
*/
node234 *sib = n->kids[ki - 1];
int lastelem = (sib->elems[2] ? 2 :
sib->elems[1] ? 1 : 0);
sub->kids[2] = sub->kids[1];
sub->counts[2] = sub->counts[1];
sub->elems[1] = sub->elems[0];
sub->kids[1] = sub->kids[0];
sub->counts[1] = sub->counts[0];
sub->elems[0] = n->elems[ki - 1];
sub->kids[0] = sib->kids[lastelem + 1];
sub->counts[0] = sib->counts[lastelem + 1];
if (sub->kids[0])
sub->kids[0]->parent = sub;
n->elems[ki - 1] = sib->elems[lastelem];
sib->kids[lastelem + 1] = NULL;
sib->counts[lastelem + 1] = 0;
sib->elems[lastelem] = NULL;
n->counts[ki] = countnode234(sub);
LOG((" case 3a left\n"));
LOG(
(" index and left subtree count before adjustment: %d, %d\n",
index, n->counts[ki - 1]));
index += n->counts[ki - 1];
n->counts[ki - 1] = countnode234(sib);
index -= n->counts[ki - 1];
LOG(
(" index and left subtree count after adjustment: %d, %d\n",
index, n->counts[ki - 1]));
} else if (ki < 3 && n->kids[ki + 1]
&& n->kids[ki + 1]->elems[1]) {
/*
* Case 3a, right-handed variant. ki has only
* one element but ki+1 has two or more. Move a
* subtree from ki+1 to ki.
*
* . B . . C .
* / \ -> / \
* a A b c C d D e [more] a A b B c d D e [more]
*/
node234 *sib = n->kids[ki + 1];
int j;
sub->elems[1] = n->elems[ki];
sub->kids[2] = sib->kids[0];
sub->counts[2] = sib->counts[0];
if (sub->kids[2])
sub->kids[2]->parent = sub;
n->elems[ki] = sib->elems[0];
sib->kids[0] = sib->kids[1];
sib->counts[0] = sib->counts[1];
for (j = 0; j < 2 && sib->elems[j + 1]; j++) {
sib->kids[j + 1] = sib->kids[j + 2];
sib->counts[j + 1] = sib->counts[j + 2];
sib->elems[j] = sib->elems[j + 1];
}
sib->kids[j + 1] = NULL;
sib->counts[j + 1] = 0;
sib->elems[j] = NULL;
n->counts[ki] = countnode234(sub);
n->counts[ki + 1] = countnode234(sib);
LOG((" case 3a right\n"));
} else {
/*
* Case 3b. ki has only one element, and has no
* neighbour with more than one. So pick a
* neighbour and merge it with ki, taking an
* element down from n to go in the middle.
*
* . B . .
* / \ -> |
* a A b c C d a A b B c C d
*
* (Since at all points we have avoided
* descending to a node with only one element,
* we can be sure that n is not reduced to
* nothingness by this move, _unless_ it was
* the very first node, ie the root of the
* tree. In that case we remove the now-empty
* root and replace it with its single large
* child as shown.)
*/
node234 *sib;
int j;
if (ki > 0) {
ki--;
index += n->counts[ki] + 1;
}
sib = n->kids[ki];
sub = n->kids[ki + 1];
sub->kids[3] = sub->kids[1];
sub->counts[3] = sub->counts[1];
sub->elems[2] = sub->elems[0];
sub->kids[2] = sub->kids[0];
sub->counts[2] = sub->counts[0];
sub->elems[1] = n->elems[ki];
sub->kids[1] = sib->kids[1];
sub->counts[1] = sib->counts[1];
if (sub->kids[1])
sub->kids[1]->parent = sub;
sub->elems[0] = sib->elems[0];
sub->kids[0] = sib->kids[0];
sub->counts[0] = sib->counts[0];
if (sub->kids[0])
sub->kids[0]->parent = sub;
n->counts[ki + 1] = countnode234(sub);
sfree(sib);
/*
* That's built the big node in sub. Now we
* need to remove the reference to sib in n.
*/
for (j = ki; j < 3 && n->kids[j + 1]; j++) {
n->kids[j] = n->kids[j + 1];
n->counts[j] = n->counts[j + 1];
n->elems[j] = j < 2 ? n->elems[j + 1] : NULL;
}
n->kids[j] = NULL;
n->counts[j] = 0;
if (j < 3)
n->elems[j] = NULL;
LOG((" case 3b ki=%d\n", ki));
if (!n->elems[0]) {
/*
* The root is empty and needs to be
* removed.
*/
LOG((" shifting root!\n"));
t->root = sub;
sub->parent = NULL;
sfree(n);
}
}
}
n = sub;
}
if (!retval)
retval = n->elems[ei];
if (ei == -1)
return NULL; /* although this shouldn't happen */
/*
* Treat special case: this is the one remaining item in
* the tree. n is the tree root (no parent), has one
* element (no elems[1]), and has no kids (no kids[0]).
*/
if (!n->parent && !n->elems[1] && !n->kids[0]) {
LOG((" removed last element in tree\n"));
sfree(n);
t->root = NULL;
return retval;
}
/*
* Now we have the element we want, as n->elems[ei], and we
* have also arranged for that element not to be the only
* one in its node. So...
*/
if (!n->kids[0] && n->elems[1]) {
/*
* Case 1. n is a leaf node with more than one element,
* so it's _really easy_. Just delete the thing and
* we're done.
*/
int i;
LOG((" case 1\n"));
for (i = ei; i < 2 && n->elems[i + 1]; i++)
n->elems[i] = n->elems[i + 1];
n->elems[i] = NULL;
/*
* Having done that to the leaf node, we now go back up
* the tree fixing the counts.
*/
while (n->parent) {
int childnum;
childnum = (n->parent->kids[0] == n ? 0 :
n->parent->kids[1] == n ? 1 :
n->parent->kids[2] == n ? 2 : 3);
n->parent->counts[childnum]--;
n = n->parent;
}
return retval; /* finished! */
} else if (n->kids[ei]->elems[1]) {
/*
* Case 2a. n is an internal node, and the root of the
* subtree to the left of e has more than one element.
* So find the predecessor p to e (ie the largest node
* in that subtree), place it where e currently is, and
* then start the deletion process over again on the
* subtree with p as target.
*/
node234 *m = n->kids[ei];
void *target;
LOG((" case 2a\n"));
while (m->kids[0]) {
m = (m->kids[3] ? m->kids[3] :
m->kids[2] ? m->kids[2] :
m->kids[1] ? m->kids[1] : m->kids[0]);
}
target = (m->elems[2] ? m->elems[2] :
m->elems[1] ? m->elems[1] : m->elems[0]);
n->elems[ei] = target;
index = n->counts[ei] - 1;
n = n->kids[ei];
} else if (n->kids[ei + 1]->elems[1]) {
/*
* Case 2b, symmetric to 2a but s/left/right/ and
* s/predecessor/successor/. (And s/largest/smallest/).
*/
node234 *m = n->kids[ei + 1];
void *target;
LOG((" case 2b\n"));
while (m->kids[0]) {
m = m->kids[0];
}
target = m->elems[0];
n->elems[ei] = target;
n = n->kids[ei + 1];
index = 0;
} else {
/*
* Case 2c. n is an internal node, and the subtrees to
* the left and right of e both have only one element.
* So combine the two subnodes into a single big node
* with their own elements on the left and right and e
* in the middle, then restart the deletion process on
* that subtree, with e still as target.
*/
node234 *a = n->kids[ei], *b = n->kids[ei + 1];
int j;
LOG((" case 2c\n"));
a->elems[1] = n->elems[ei];
a->kids[2] = b->kids[0];
a->counts[2] = b->counts[0];
if (a->kids[2])
a->kids[2]->parent = a;
a->elems[2] = b->elems[0];
a->kids[3] = b->kids[1];
a->counts[3] = b->counts[1];
if (a->kids[3])
a->kids[3]->parent = a;
sfree(b);
n->counts[ei] = countnode234(a);
/*
* That's built the big node in a, and destroyed b. Now
* remove the reference to b (and e) in n.
*/
for (j = ei; j < 2 && n->elems[j + 1]; j++) {
n->elems[j] = n->elems[j + 1];
n->kids[j + 1] = n->kids[j + 2];
n->counts[j + 1] = n->counts[j + 2];
}
n->elems[j] = NULL;
n->kids[j + 1] = NULL;
n->counts[j + 1] = 0;
/*
* It's possible, in this case, that we've just removed
* the only element in the root of the tree. If so,
* shift the root.
*/
if (n->elems[0] == NULL) {
LOG((" shifting root!\n"));
t->root = a;
a->parent = NULL;
sfree(n);
}
/*
* Now go round the deletion process again, with n
* pointing at the new big node and e still the same.
*/
n = a;
index = a->counts[0] + a->counts[1] + 1;
}
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *delpos234(tree234 *t, int index)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (index < 0 || index >= countnode234(t->root))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return delpos234_internal(t, index);
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
void *del234(tree234 *t, void *e)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int index;
if (!findrelpos234(t, e, NULL, REL234_EQ, &index))
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return NULL; /* it wasn't in there anyway */
return delpos234_internal(t, index); /* it's there; delete it. */
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
#ifdef TEST
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/*
* Test code for the 2-3-4 tree. This code maintains an alternative
* representation of the data in the tree, in an array (using the
* obvious and slow insert and delete functions). After each tree
Make the new test suite's comment more accurate :-) [originally from svn r663]
2000-10-02 13:57:41 +00:00
* operation, the verify() function is called, which ensures all
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* the tree properties are preserved:
* - node->child->parent always equals node
* - tree->root->parent always equals NULL
* - number of kids == 0 or number of elements + 1;
* - tree has the same depth everywhere
* - every node has at least one element
* - subtree element counts are accurate
* - any NULL kid pointer is accompanied by a zero count
* - in a sorted tree: ordering property between elements of a
* node and elements of its children is preserved
* and also ensures the list represented by the tree is the same
* list it should be. (This last check also doubly verifies the
* ordering properties, because the `same list it should be' is by
* definition correctly ordered. It also ensures all nodes are
* distinct, because the enum functions would get caught in a loop
* if not.)
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
*/
#include <stdarg.h>
tree234.c: minor fixes to the test suite. Added a missing #include of string.h; arranged that the test program reports the number of errors detected at the end so I don't have to search its entire output for "ERROR"; made the test program return a nonzero exit status if any error was found.
2018-09-19 11:57:33 +00:00
#include <string.h>
int n_errors = 0;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/*
* Error reporting function.
*/
Greatly improve printf format-string checking. I've added the gcc-style attribute("printf") to a lot of printf-shaped functions in this code base that didn't have it. To make that easier, I moved the wrapping macro into defs.h, and also enabled it if we detect the __clang__ macro as well as __GNU__ (hence, it will be used when building for Windows using clang-cl). The result is that a great many format strings in the code are now checked by the compiler, where they were previously not. This causes build failures, which I'll fix in the next commit.
2020-01-26 14:49:31 +00:00
PRINTF_LIKE(1, 2) void error(char *fmt, ...)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
va_list ap;
printf("ERROR: ");
va_start(ap, fmt);
vfprintf(stdout, fmt, ap);
va_end(ap);
printf("\n");
tree234.c: minor fixes to the test suite. Added a missing #include of string.h; arranged that the test program reports the number of errors detected at the end so I don't have to search its entire output for "ERROR"; made the test program return a nonzero exit status if any error was found.
2018-09-19 11:57:33 +00:00
n_errors++;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
/* The array representation of the data. */
void **array;
int arraylen, arraysize;
cmpfn234 cmp;
/* The tree representation of the same data. */
tree234 *tree;
typedef struct {
int treedepth;
int elemcount;
} chkctx;
Formatting: remove spurious spaces in 'type * var'. I think a lot of these were inserted by a prior run through GNU indent many years ago. I noticed in a more recent experiment that that tool doesn't always correctly distinguish which instances of 'id * id' are pointer variable declarations and which are multiplications, so it spaces some of the former as if they were the latter.
2022-08-03 19:48:46 +00:00
int chknode(chkctx *ctx, int level, node234 *node,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *lowbound, void *highbound)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
int nkids, nelems;
int i;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int count;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/* Count the non-NULL kids. */
for (nkids = 0; nkids < 4 && node->kids[nkids]; nkids++);
/* Ensure no kids beyond the first NULL are non-NULL. */
for (i = nkids; i < 4; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (node->kids[i]) {
error("node %p: nkids=%d but kids[%d] non-NULL",
node, nkids, i);
} else if (node->counts[i]) {
error("node %p: kids[%d] NULL but count[%d]=%d nonzero",
node, i, i, node->counts[i]);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/* Count the non-NULL elements. */
for (nelems = 0; nelems < 3 && node->elems[nelems]; nelems++);
/* Ensure no elements beyond the first NULL are non-NULL. */
for (i = nelems; i < 3; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (node->elems[i]) {
error("node %p: nelems=%d but elems[%d] non-NULL",
node, nelems, i);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
if (nkids == 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If nkids==0, this is a leaf node; verify that the tree
* depth is the same everywhere.
*/
if (ctx->treedepth < 0)
ctx->treedepth = level; /* we didn't know the depth yet */
else if (ctx->treedepth != level)
error("node %p: leaf at depth %d, previously seen depth %d",
node, level, ctx->treedepth);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
} else {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/*
* If nkids != 0, then it should be nelems+1, unless nelems
* is 0 in which case nkids should also be 0 (and so we
* shouldn't be in this condition at all).
*/
int shouldkids = (nelems ? nelems + 1 : 0);
if (nkids != shouldkids) {
error("node %p: %d elems should mean %d kids but has %d",
node, nelems, shouldkids, nkids);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
/*
* nelems should be at least 1.
*/
if (nelems == 0) {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
error("node %p: no elems", node);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
/*
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
* Add nelems to the running element count of the whole tree.
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
*/
ctx->elemcount += nelems;
/*
* Check ordering property: all elements should be strictly >
* lowbound, strictly < highbound, and strictly < each other in
* sequence. (lowbound and highbound are NULL at edges of tree
* - both NULL at root node - and NULL is considered to be <
* everything and > everything. IYSWIM.)
*/
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (cmp) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
for (i = -1; i < nelems; i++) {
void *lower = (i == -1 ? lowbound : node->elems[i]);
void *higher =
(i + 1 == nelems ? highbound : node->elems[i + 1]);
if (lower && higher && cmp(lower, higher) >= 0) {
error("node %p: kid comparison [%d=%s,%d=%s] failed",
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
node, i, (char *)lower, i + 1, (char *)higher);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
/*
* Check parent pointers: all non-NULL kids should have a
* parent pointer coming back to this node.
*/
for (i = 0; i < nkids; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (node->kids[i]->parent != node) {
error("node %p kid %d: parent ptr is %p not %p",
node, i, node->kids[i]->parent, node);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/*
* Now (finally!) recurse into subtrees.
*/
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
count = nelems;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
for (i = 0; i < nkids; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *lower = (i == 0 ? lowbound : node->elems[i - 1]);
void *higher = (i >= nelems ? highbound : node->elems[i]);
int subcount =
chknode(ctx, level + 1, node->kids[i], lower, higher);
if (node->counts[i] != subcount) {
error("node %p kid %d: count says %d, subtree really has %d",
node, i, node->counts[i], subcount);
}
count += subcount;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
return count;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void verify(void)
{
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
chkctx ctx[1];
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
int i;
void *p;
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
ctx->treedepth = -1; /* depth unknown yet */
ctx->elemcount = 0; /* no elements seen yet */
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/*
* Verify validity of tree properties.
*/
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (tree->root) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (tree->root->parent != NULL)
error("root->parent is %p should be null", tree->root->parent);
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
chknode(ctx, 0, tree->root, NULL, NULL);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("tree depth: %d\n", ctx->treedepth);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/*
* Enumerate the tree and ensure it matches up to the array.
*/
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
for (i = 0; NULL != (p = index234(tree, i)); i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (i >= arraylen)
error("tree contains more than %d elements", arraylen);
if (array[i] != p)
error("enum at position %d: array says %s, tree says %s",
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
i, (char *)array[i], (char *)p);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
if (ctx->elemcount != i) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("tree really contains %d elements, enum gave %d",
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
ctx->elemcount, i);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
if (i < arraylen) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("enum gave only %d elements, array has %d", i, arraylen);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
i = count234(tree);
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
if (ctx->elemcount != i) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("tree really contains %d elements, count234 gave %d",
Refactor 'struct context *ctx = &actx' pattern. When I'm declaring a local instance of some context structure type to pass to a function which will pass it in turn to a callback, I've tended to use a declaration of the form struct context actx, *ctx = &actx; so that the outermost caller can initialise the context, and/or read out fields of it afterwards, by the same syntax 'ctx->foo' that the callback function will be using. So you get visual consistency between the two functions that share this context. It only just occurred to me that there's a much neater way to declare a context struct of this kind, which still makes 'ctx' behave like a pointer in the owning function, and doesn't need all that weird verbiage or a spare variable name: struct context ctx[1]; That's much nicer! I've switched to doing that in all existing cases I could find, and also in a couple of cases where I hadn't previously bothered to do the previous more cumbersome idiom.
2019-12-22 08:15:52 +00:00
ctx->elemcount, i);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void internal_addtest(void *elem, int index, void *realret)
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
int i, j;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
void *retval;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (arraysize < arraylen + 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
arraysize = arraylen + 1 + 256;
array = sresize(array, arraysize, void *);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
i = index;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/* now i points to the first element >= elem */
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
retval = elem; /* expect elem returned (success) */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
for (j = arraylen; j > i; j--)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
array[j] = array[j - 1];
array[i] = elem; /* add elem to array */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
arraylen++;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
if (realret != retval) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("add: retval was %p expected %p", realret, retval);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
verify();
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void addtest(void *elem)
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
int i;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
void *realret;
realret = add234(tree, elem);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
i = 0;
while (i < arraylen && cmp(elem, array[i]) > 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
i++;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (i < arraylen && !cmp(elem, array[i])) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
void *retval = array[i]; /* expect that returned not elem */
if (realret != retval) {
error("add: retval was %p expected %p", realret, retval);
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
internal_addtest(elem, i, realret);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void addpostest(void *elem, int i)
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
void *realret;
realret = addpos234(tree, elem, i);
internal_addtest(elem, i, realret);
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void delpostest(int i)
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int index = i;
void *elem = array[i], *ret;
/* i points to the right element */
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
while (i < arraylen - 1) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
array[i] = array[i + 1];
i++;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
arraylen--; /* delete elem from array */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (tree->cmp)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = del234(tree, elem);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ret = delpos234(tree, index);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (ret != elem) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("del returned %p, expected %p", ret, elem);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
verify();
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void deltest(void *elem)
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int i;
i = 0;
while (i < arraylen && cmp(elem, array[i]) > 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
i++;
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
if (i >= arraylen || cmp(elem, array[i]) != 0)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return; /* don't do it! */
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
delpostest(i);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
/* A sample data set and test utility. Designed for pseudo-randomness,
* and yet repeatability. */
/*
* This random number generator uses the `portable implementation'
* given in ANSI C99 draft N869. It assumes `unsigned' is 32 bits;
* change it if not.
*/
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
int randomnumber(unsigned *seed)
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
*seed *= 1103515245;
*seed += 12345;
return ((*seed) / 65536) % 32768;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
int mycmp(void *av, void *bv)
{
char const *a = (char const *) av;
char const *b = (char const *) bv;
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
return strcmp(a, b);
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
#define lenof(x) ( sizeof((x)) / sizeof(*(x)) )
char *strings[] = {
"a", "ab", "absque", "coram", "de",
"palam", "clam", "cum", "ex", "e",
"sine", "tenus", "pro", "prae",
"banana", "carrot", "cabbage", "broccoli", "onion", "zebra",
"penguin", "blancmange", "pangolin", "whale", "hedgehog",
"giraffe", "peanut", "bungee", "foo", "bar", "baz", "quux",
"murfl", "spoo", "breen", "flarn", "octothorpe",
"snail", "tiger", "elephant", "octopus", "warthog", "armadillo",
"aardvark", "wyvern", "dragon", "elf", "dwarf", "orc", "goblin",
"pixie", "basilisk", "warg", "ape", "lizard", "newt", "shopkeeper",
"wand", "ring", "amulet"
};
#define NSTR lenof(strings)
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
void findtest(void)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
const static int rels[] = {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
REL234_EQ, REL234_GE, REL234_LE, REL234_LT, REL234_GT
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
};
const static char *const relnames[] = {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"EQ", "GE", "LE", "LT", "GT"
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
};
int i, j, rel, index;
char *p, *ret, *realret, *realret2;
int lo, hi, mid, c;
for (i = 0; i < NSTR; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
p = strings[i];
for (j = 0; j < sizeof(rels) / sizeof(*rels); j++) {
rel = rels[j];
lo = 0;
hi = arraylen - 1;
while (lo <= hi) {
mid = (lo + hi) / 2;
c = strcmp(p, array[mid]);
if (c < 0)
hi = mid - 1;
else if (c > 0)
lo = mid + 1;
else
break;
}
if (c == 0) {
if (rel == REL234_LT)
ret = (mid > 0 ? array[--mid] : NULL);
else if (rel == REL234_GT)
ret = (mid < arraylen - 1 ? array[++mid] : NULL);
else
ret = array[mid];
} else {
assert(lo == hi + 1);
if (rel == REL234_LT || rel == REL234_LE) {
mid = hi;
ret = (hi >= 0 ? array[hi] : NULL);
} else if (rel == REL234_GT || rel == REL234_GE) {
mid = lo;
ret = (lo < arraylen ? array[lo] : NULL);
} else
ret = NULL;
}
realret = findrelpos234(tree, p, NULL, rel, &index);
if (realret != ret) {
error("find(\"%s\",%s) gave %s should be %s",
p, relnames[j], realret, ret);
}
if (realret && index != mid) {
error("find(\"%s\",%s) gave %d should be %d",
p, relnames[j], index, mid);
}
if (realret && rel == REL234_EQ) {
realret2 = index234(tree, index);
if (realret2 != realret) {
error("find(\"%s\",%s) gave %s(%d) but %d -> %s",
p, relnames[j], realret, index, index, realret2);
}
}
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("find(\"%s\",%s) gave %s(%d)\n", p, relnames[j],
realret, index);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
realret = findrelpos234(tree, NULL, NULL, REL234_GT, &index);
if (arraylen && (realret != array[0] || index != 0)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("find(NULL,GT) gave %s(%d) should be %s(0)",
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
realret, index, (char *)array[0]);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
} else if (!arraylen && (realret != NULL)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("find(NULL,GT) gave %s(%d) should be NULL", realret, index);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
realret = findrelpos234(tree, NULL, NULL, REL234_LT, &index);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (arraylen
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
&& (realret != array[arraylen - 1] || index != arraylen - 1)) {
error("find(NULL,LT) gave %s(%d) should be %s(0)", realret, index,
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
(char *)array[arraylen - 1]);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
} else if (!arraylen && (realret != NULL)) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
error("find(NULL,LT) gave %s(%d) should be NULL", realret, index);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
}
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
void searchtest_recurse(search234_state ss, int lo, int hi,
char **expected, char *directionbuf,
char *directionptr)
{
*directionptr = '\0';
if (!ss.element) {
if (lo != hi) {
error("search234(%s) gave NULL for non-empty interval [%d,%d)",
directionbuf, lo, hi);
} else if (ss.index != lo) {
error("search234(%s) gave index %d should be %d",
directionbuf, ss.index, lo);
} else {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("%*ssearch234(%s) gave NULL,%d\n",
(int)(directionptr-directionbuf) * 2, "", directionbuf,
ss.index);
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
}
} else if (lo == hi) {
error("search234(%s) gave %s for empty interval [%d,%d)",
directionbuf, (char *)ss.element, lo, hi);
} else if (ss.element != expected[ss.index]) {
error("search234(%s) gave element %s should be %s",
directionbuf, (char *)ss.element, expected[ss.index]);
} else if (ss.index < lo || ss.index >= hi) {
error("search234(%s) gave index %d should be in [%d,%d)",
directionbuf, ss.index, lo, hi);
return;
} else {
search234_state next;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("%*ssearch234(%s) gave %s,%d\n",
(int)(directionptr-directionbuf) * 2, "", directionbuf,
(char *)ss.element, ss.index);
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
next = ss;
search234_step(&next, -1);
*directionptr = '-';
searchtest_recurse(next, lo, ss.index,
expected, directionbuf, directionptr+1);
next = ss;
search234_step(&next, +1);
*directionptr = '+';
searchtest_recurse(next, ss.index+1, hi,
expected, directionbuf, directionptr+1);
}
}
void searchtest(void)
{
char *expected[NSTR], *p;
char directionbuf[NSTR * 10];
int n;
search234_state ss;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("beginning searchtest:");
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
for (n = 0; (p = index234(tree, n)) != NULL; n++) {
expected[n] = p;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf(" %d=%s", n, p);
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
}
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf(" count=%d\n", n);
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
search234_start(&ss, tree);
searchtest_recurse(ss, 0, n, expected, directionbuf, directionbuf);
}
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
void out_of_memory(void)
{
fprintf(stderr, "out of memory!\n");
exit(2);
}
int main(int argc, char **argv)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
int in[NSTR];
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
int i, j, k;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
unsigned seed = 0;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
for (i = 1; i < argc; i++) {
char *arg = argv[i];
if (!strcmp(arg, "-v")) {
verbose++;
} else {
fprintf(stderr, "unrecognised option '%s'\n", arg);
return 1;
}
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
for (i = 0; i < NSTR; i++)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
in[i] = 0;
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
array = NULL;
arraylen = arraysize = 0;
tree = newtree234(mycmp);
cmp = mycmp;
verify();
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
searchtest();
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
for (i = 0; i < 10000; i++) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
j = randomnumber(&seed);
j %= NSTR;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("trial: %d\n", i);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (in[j]) {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("deleting %s (%d)\n", strings[j], j);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
deltest(strings[j]);
in[j] = 0;
} else {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("adding %s (%d)\n", strings[j], j);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
addtest(strings[j]);
in[j] = 1;
}
findtest();
tree234.c: new search234() system. This is a thing I've been meaning to set up for a while: it's a pull-based search system (that is, the caller takes each step of the search manually, rather than providing a callback), which lets the caller inspect every step of the search, including the index of each candidate element in the tree. This allows flexible kinds of query that play the element and its index off against each other. I've also rewritten the existing findrelpos234() search function using the new one as a primitive, because that simplifies it a lot!
2018-09-19 11:58:54 +00:00
searchtest();
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
while (arraylen > 0) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
j = randomnumber(&seed);
j %= arraylen;
deltest(array[j]);
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
}
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
freetree234(tree);
/*
* Now try an unsorted tree. We don't really need to test
* delpos234 because we know del234 is based on it, so it's
* already been tested in the above sorted-tree code; but for
* completeness we'll use it to tear down our unsorted tree
* once we've built it.
*/
tree = newtree234(NULL);
cmp = NULL;
verify();
for (i = 0; i < 1000; i++) {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("trial: %d\n", i);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
j = randomnumber(&seed);
j %= NSTR;
k = randomnumber(&seed);
k %= count234(tree) + 1;
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("adding string %s at index %d\n", strings[j], k);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
addpostest(strings[j], k);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
while (count234(tree) > 0) {
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("cleanup: tree size %d\n", count234(tree));
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
j = randomnumber(&seed);
j %= count234(tree);
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
if (verbose)
printf("deleting string %s from index %d\n",
(const char *)array[j], j);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
delpostest(j);
Replace PuTTY's 2-3-4 tree implementation with the shiny new counted one, in preparation for using it to speed up scrollback. [originally from svn r1053]
2001-04-16 17:18:24 +00:00
}
tree234.c: minor fixes to the test suite. Added a missing #include of string.h; arranged that the test program reports the number of errors detected at the end so I don't have to search its entire output for "ERROR"; made the test program return a nonzero exit status if any error was found.
2018-09-19 11:57:33 +00:00
printf("%d errors found\n", n_errors);
return (n_errors != 0);
2-3-4 tree routines [originally from svn r590]
2000-09-14 15:02:50 +00:00
}
Shiny new test harness for the 2-3-4 tree [originally from svn r658]
2000-10-02 11:46:10 +00:00
Build various unit-test main() programs in utils. I found these while going through the code, and decided if we're going to have them then we should compile them. They didn't all compile first time, proving my point :-) I've enhanced the tree234 test so that it has a verbose option, which by default is off.
2021-04-17 15:39:31 +00:00
#endif /* TEST */
Reference in New Issue Copy Permalink