roestvrijstaal/cityhash

Automatically exported from code.google.com/p/cityhash

cityhash's Issues

OpenBSD Patch

Recently noticed a downstream use of cityhash had trouble with compiling on 
FreeBSD and independently reached the same conclusion as 
https://code.google.com/p/cityhash/issues/detail?id=12.

At the same time, also looked into whether OpenBSD might have a similar issue.  
Believe something like the attached will be needed for OpenBSD, though do not 
have an OpenBSD machine to test on currently.

Original issue reported on code.google.com by [email protected] on 28 Jul 2013 at 4:39

Attachments:

• city.cc.diff

CityHash128 will not build on Windows (x64)

What steps will reproduce the problem?

1. Attempt to build x64 version of CityHash using VS2008 results in build error 
C2065: 'ssize_t' undeclared identifier.


Workaround:

Add:

#define ssize_t long

...just after #include statements near beginning of CityHash.cpp. This resolves 
the undefined identifier type.

Original issue reported on code.google.com by [email protected] on 24 May 2011 at 9:16

[FreeBSD]: added support FreeBSD build.

I'm added patch with fix for build on FreeBSD.

Thank you.

Original issue reported on code.google.com by G.Veniamin on 25 Dec 2012 at 1:01

Attachments:

• patch-src_city.cc

Hash of a+b given hashes of a and b

A comment in city.h says:
// By the way, for some hash functions, given strings a and b, the hash
// of a+b is easily derived from the hashes of a and b.  This property
// doesn't hold for any hash functions in this file.

But I didn't find how it can be done. It would be nice to have this feature. 
For example, it can be used to hash a data stream that becomes available one 
block at a time, but the block sizes are arbitrary, and we need both the hash 
of each block and the hash of the whole stream (invariant of block sizes).

Original issue reported on code.google.com by [email protected] on 26 Mar 2014 at 9:54

demand for auto detect SSE4.2

this may help:

https://gitorious.org/cityhash_c/cityhash_c/blobs/master/configure.ac

Original issue reported on code.google.com by [email protected] on 4 Aug 2011 at 3:45

extern "C" interface

Please provide any additional information below.

Any chance of an extern "C" interface in header files compatible with C 
programs? C programs don't like typedef std::pair<uint64, uint64> uint128 
unfortunately.

Original issue reported on code.google.com by [email protected] on 8 Feb 2012 at 8:15

CVE-2012-6051

From http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6051

> Google CityHash computes hash values without properly restricting the 
> ability to trigger hash collisions predictably, which allows context-
> dependent attackers to cause a denial of service (CPU consumption) via 
> crafted input to an application that maintains a hash table, as 
> demonstrated by a universal multicollision attack.

Given that the NEWS file does not mention this, is v1.1.0 affected?

Original issue reported on code.google.com by Al3xBio on 3 Dec 2012 at 10:40

UnsignedLongs.join error

UnsignedLongs.join does not treat the first long from its arguments as unsigned.

builder.append(array[0]);
for (int i = 1; i < array.length; i++) {
  builder.append(separator).append(toString(array[i]));
}

where it should be builder.append(toString(array[0])).

Original issue reported on code.google.com by wasserman.louis on 9 Apr 2012 at 10:37

Warning on build.

What steps will reproduce the problem?
1. Build for x64 gcc with -Wsign-compare.
2. Observe warning.

What is the expected output? What do you see instead?
No warnings.

../../third_party/externals/cityhash/src/city.cc:146:21: warning: comparison of 
integers of different signs: 'int' and 'size_t' (aka 'unsigned long') 
[-Wsign-compare]
  for (int i = 0; i < len; i++) {
                  ~ ^ ~~~
1 warning generated.


What version of the product are you using? On what operating system?
Revision 11.

Please provide any additional information below.
Patch attached. With patch the exact same code appears to be generated (with 
Release style compile settings) but no warning diagnostic is emitted.

Original issue reported on code.google.com by [email protected] on 7 Dec 2012 at 5:01

Attachments:

• size_t.diff

[PATCH] Include sys/byteorder.h on Solaris

Add build support for Solaris.

Original issue reported on code.google.com by [email protected] on 17 Jan 2013 at 3:38

Attachments:

• 001-solaris-byteorder.patch

Test vectors

Some test vectors to check whether CityHash has been compiled and executes 
correctly or whether another implementation produces the same output would be 
greatly appreciated.

Original issue reported on code.google.com by [email protected] on 13 Apr 2011 at 7:25

Non alpha-numeric characters do not get hashed

What steps will reproduce the problem?
1. char foo[11] = "Hello, World!"; char bar[11] = "Hello, World?";
2. uint128 _foo = CityHash128(foo, 11); uint128 _bar = CityHash128(bar, 11);
3. Print the results. They are the same.

What is the expected output? What do you see instead? I expect a different 
number. I see two identical ones.


What version of the product are you using? On what operating system? Linux 
(Debian/Ubuntu 12.04) 64-bit AMD. Using version 1.03.


Please provide any additional information below.
It may be that this was done on purpose, but if not, I wanted to bring it to 
your attention!

Original issue reported on code.google.com by [email protected] on 11 Jun 2012 at 7:48

CityHash128 isn't thorough enough

What steps will reproduce the problem?
1. CityHash128() all 144-byte strings with 3 bits set
2. check for collisions

What is the expected output? What do you see instead?

0 collisions are expected.  87 collisions are actually seen.  I saw the first 
collision after about 8 million of the keys.  That's the expected collision 
rate for a 46-bit hash, not a 128-bit hash.

(I had a hash of my own last year, AkronHash, that was also a 128-bit hash 
evolved from MurmurHash.  I quickly withdrew it due to similar quality issues.  
My current attempt, SpookyHash, passes this test.)

Original issue reported on code.google.com by [email protected] on 28 Jul 2011 at 8:00

Given the exact same input twice,the hash function produce the different output

 Given the exact same input twice, the hash function should always produce the same output. I cann't understand why cityhash32 and cityhash64 function produce the different output when giving the exact same input string twice.

Original issue reported on code.google.com by [email protected] on 23 Aug 2013 at 2:40

Add CityHash32

It would be nice to have a 32-bit version for use in e.g. hash table 
implementations on 32-bit systems.

Original issue reported on code.google.com by [email protected] on 19 Apr 2011 at 8:05

32 platforms

Do you have any plan for implementing them for 32 platforms ?

Having this stuff only for 64 bit platforms is really limiting, as most 
software has to still support 32 bits.

The 128 and CRC variants could be really useful for 32 bits.

Original issue reported on code.google.com by [email protected] on 28 Jan 2012 at 8:57

Branching in Rotate function

I noticed the following code in the rotate function:

static uint64 Rotate(uint64 val, int shift)
{
  // Avoid shifting by 64: doing so yields an undefined result.
  return shift == 0 ? val : ((val >> shift) | (val << (64 - shift)));
}

Wouldn't it be faster to do an additional bitwise-and instead of introducing 
branching? For example:

  return ( (val >> shift) | ( val << ((64 - shift) & 63) ) );

Original issue reported on code.google.com by [email protected] on 13 Feb 2013 at 12:36