summaryrefslogtreecommitdiffstats
path: root/tests/baselineserver
diff options
context:
space:
mode:
Diffstat (limited to 'tests/baselineserver')
-rw-r--r--tests/baselineserver/shared/lookup3.cpp32
1 files changed, 16 insertions, 16 deletions
diff --git a/tests/baselineserver/shared/lookup3.cpp b/tests/baselineserver/shared/lookup3.cpp
index b2d9ffeb94..2959356ca8 100644
--- a/tests/baselineserver/shared/lookup3.cpp
+++ b/tests/baselineserver/shared/lookup3.cpp
@@ -47,8 +47,8 @@ These functions are based on:
lookup3.c, by Bob Jenkins, May 2006, Public Domain.
These are functions for producing 32-bit hashes for hash table lookup.
-hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final()
-are externally useful functions. Routines to test the hash are included
+hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final()
+are externally useful functions. Routines to test the hash are included
if SELF_TEST is defined. You can use this free for any purpose. It's in
the public domain. It has no warranty.
@@ -56,7 +56,7 @@ You probably want to use hashlittle(). hashlittle() and hashbig()
hash byte arrays. hashlittle() is is faster than hashbig() on
little-endian machines. Intel and AMD are little-endian machines.
On second thought, you probably want hashlittle2(), which is identical to
-hashlittle() except it returns two 32-bit hashes for the price of one.
+hashlittle() except it returns two 32-bit hashes for the price of one.
You could implement hashbig2() if you wanted but I haven't bothered here.
If you want to find a hash of, say, exactly 7 integers, do
@@ -69,9 +69,9 @@ If you want to find a hash of, say, exactly 7 integers, do
then use c as the hash value. If you have a variable length array of
4-byte integers to hash, use hashword(). If you have a byte array (like
a character string), use hashlittle(). If you have several byte arrays, or
-a mix of things, see the comments above hashlittle().
+a mix of things, see the comments above hashlittle().
-Why is this so big? I read 12 bytes at a time into 3 4-byte integers,
+Why is this so big? I read 12 bytes at a time into 3 4-byte integers,
then mix those integers. This is fast (you can do a lot more thorough
mixing with 12*3 instructions on 3 integers than you can with 3 instructions
on 1 byte), but shoehorning those bytes into integers efficiently is messy.
@@ -110,7 +110,7 @@ This was tested for:
the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
is commonly produced by subtraction) look like a single 1-bit
difference.
-* the base values were pseudorandom, all zero but one bit set, or
+* the base values were pseudorandom, all zero but one bit set, or
all zero plus a counter that starts at zero.
Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that
@@ -120,7 +120,7 @@ satisfy this are
14 9 3 7 17 3
Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing
for "differ" defined as + with a one-bit base and a two-bit delta. I
-used http://burtleburtle.net/bob/hash/avalanche.html to choose
+used http://burtleburtle.net/bob/hash/avalanche.html to choose
the operations, constants, and arrangements of the variables.
This does not achieve avalanche. There are input bits of (a,b,c)
@@ -159,7 +159,7 @@ produce values of c that look totally different. This was tested for
the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
is commonly produced by subtraction) look like a single 1-bit
difference.
-* the base values were pseudorandom, all zero but one bit set, or
+* the base values were pseudorandom, all zero but one bit set, or
all zero plus a counter that starts at zero.
These constants passed:
@@ -218,7 +218,7 @@ quint32 initval) /* the previous hash, or an arbitrary value */
/*------------------------------------------- handle the last 3 quint32's */
switch(length) /* all the case statements fall through */
- {
+ {
case 3 : c+=k[2];
case 2 : b+=k[1];
case 1 : a+=k[0];
@@ -235,7 +235,7 @@ quint32 initval) /* the previous hash, or an arbitrary value */
--------------------------------------------------------------------
hashword2() -- same as hashword(), but take two seeds and return two
32-bit values. pc and pb must both be nonnull, and *pc and *pb must
-both be initialized with seeds. If you pass in (*pb)==0, the output
+both be initialized with seeds. If you pass in (*pb)==0, the output
(*pc) will be the same as the return value from hashword().
--------------------------------------------------------------------
*/
@@ -264,7 +264,7 @@ quint32 *pb) /* IN: more seed OUT: secondary hash value */
/*------------------------------------------- handle the last 3 quint32's */
switch(length) /* all the case statements fall through */
- {
+ {
case 3 : c+=k[2];
case 2 : b+=k[1];
case 1 : a+=k[0];
@@ -328,7 +328,7 @@ quint32 hashlittle( const void *key, size_t length, quint32 initval)
}
/*----------------------------- handle the last (probably partial) block */
- /*
+ /*
* "k[2]&0xffffff" actually reads beyond the end of the string, but
* then masks off the part it's not allowed to read. Because the
* string is aligned, the masked-off tail is in the same word as the
@@ -483,7 +483,7 @@ quint32 hashlittle( const void *key, size_t length, quint32 initval)
* the key. *pc is better mixed than *pb, so use *pc first. If you want
* a 64-bit value do something like "*pc + (((uint64_t)*pb)<<32)".
*/
-void hashlittle2(
+void hashlittle2(
const void *key, /* the key to hash */
size_t length, /* length of the key */
quint32 *pc, /* IN: primary initval, OUT: primary hash */
@@ -512,7 +512,7 @@ void hashlittle2(
}
/*----------------------------- handle the last (probably partial) block */
- /*
+ /*
* "k[2]&0xffffff" actually reads beyond the end of the string, but
* then masks off the part it's not allowed to read. Because the
* string is aligned, the masked-off tail is in the same word as the
@@ -662,7 +662,7 @@ void hashlittle2(
* hashbig():
* This is the same as hashword() on big-endian machines. It is different
* from hashlittle() on all machines. hashbig() takes advantage of
- * big-endian byte ordering.
+ * big-endian byte ordering.
*/
quint32 hashbig( const void *key, size_t length, quint32 initval)
{
@@ -688,7 +688,7 @@ quint32 hashbig( const void *key, size_t length, quint32 initval)
}
/*----------------------------- handle the last (probably partial) block */
- /*
+ /*
* "k[2]<<8" actually reads beyond the end of the string, but
* then shifts out the part it's not allowed to read. Because the
* string is aligned, the illegal read is in the same word as the