Displaying 6 results from an estimated 6 matches for "tag_tabl".
Did you mean:
tag_table
2003 Oct 05
2
Possible security hole
Maybe security related mails should be sent elsewhere? I didn't notice
any so here it goes:
sender.c:receive_sums()
s->count = read_int(f);
..
s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count);
if (!s->sums) out_of_memory("receive_sums");
for (i=0; i < (int) s->count;i++) {
s->sums[i].sum1 = read_int(f);
2004 Jan 27
1
Init array to -1 with memset()?
...-------------
--- match.c 3 Jan 2004 19:28:03 -0000 1.60
+++ match.c 27 Jan 2004 17:04:22 -0000
@@ -75,8 +75,12 @@ static void build_hash_table(struct sum_
qsort(targets,s->count,sizeof(targets[0]),(int (*)())compare_targets);
+#ifdef WEIRD_MINUS_ONE
for (i = 0; i < TABLESIZE; i++)
tag_table[i] = NULL_TAG;
+#else
+ memset((char *)tag_table, 0xFF, TABLESIZE * sizeof *tag_table);
+#endif
for (i = s->count; i-- > 0; )
tag_table[targets[i].t] = i;
2004 Jan 26
1
How match.c hash_search works with multiple checksums that have identical tags
...ight. This is usually a sign that I am missing something obvious.
Here is what I see.
build_hash_table uses qsort to order targets in ascending order of //tag,index// into the array of checksums.
It then accesses the targets in ascending order and writes the index at the tag's location in the tag_table. For any
set of targets with identical tags, the highest valued index is the resulting value in that location in the table.
hash_search initializes "j" from the tag_table resulting in "j" being the largest index in a group of targets with the same
tag value. The for loop that...
2002 Mar 23
1
why variable last_i is needed in match.c rsync source ?
Hi all
I see the rsync source and rsync makes hashing table and search hashing
table tag_table to find the index of array struct sum_buf , which is a
element of struct sum_struct.
According to the source code, variable last_i is used to encourage
adjacent matches allowing the RLL coding of the output to work more
efficiently.
Why last_i makes more efficiency?
I can't understanding w...
2004 Jun 19
1
[Bug 1467] Hash table generation seems to be flawed
https://bugzilla.samba.org/show_bug.cgi?id=1467
------- Additional Comments From ripper@internode.on.net 2004-06-19 02:18 -------
The way the code seems to work is as follows:
A sorted list of hashes and their block numbers are generated (targets).
They're sorted so that identical hashes are numerically next to each other.
A reverse lookup table is then generated, that (i presume) is
2002 Aug 05
5
[patch] read-devices
...nt);
- do {
+ while (k >= s->sums[s->count-1].len) { /* look for a matching chunk as long as it might exist */
tag t = gettag2(s1,s2);
int done_csum2 = 0;
-
+ if (verbose>4) rprintf(FINFO, "#ET#>hash_search: iteration, offset=%.0f\n", (double)offset);
+
j = tag_table[t];
if (verbose > 4)
rprintf(FINFO,"offset=%.0f sum=%08x\n",(double)offset,sum);
@@ -175,23 +172,26 @@
sum = (s1 & 0xffff) | (s2 << 16);
tag_hits++;
for (; j < (int) s->count && targets[j].t == t; j++) {
- int l, i = targets[j].i;
+ in...