diff options
author | Axel Waggershauser <awagger@gmail.com> | 2013-03-15 00:42:15 +0100 |
---|---|---|
committer | The Qt Project <gerrit-noreply@qt-project.org> | 2013-03-16 20:22:50 +0100 |
commit | b11317a64339f5a4bcffc8234ecaf15c7fb416f2 (patch) | |
tree | f81e40ee49f5109b4100048d131d5bb922b448aa /tests/baselineserver | |
parent | 72367a94a750355eb748793ce8c365373a332c9c (diff) |
Whitespace cleanup: remove trailing whitespace
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Diffstat (limited to 'tests/baselineserver')
-rw-r--r-- | tests/baselineserver/shared/lookup3.cpp | 32 |
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 |