On Dec 28, 2007, at 4:35 AM, Ivan Voras wrote:
Garrett Cooper wrote:
Looks promising, but how difficult would it be to port the
code to other platforms (Win32 for instance?).
The hash algorithm itself as implemented in hash.h is pretty much a
text-book hash algorithm (D.J.Bernstein's):
#ifndef HASHINIT
#define HASHINIT 5381
#define HASHSTEP(x,c) (((x << 5) + x) + (c))
#endif
/*
* Return a 32-bit hash of the given buffer. The init
* value should be 0, or the previous hash value to extend
* the previous hash.
*/
static __inline uint32_t
hash32_buf(const void *buf, size_t len, uint32_t hash)
{
const unsigned char *p = buf;
while (len--)
hash = HASHSTEP(hash, *p++);
return hash;
}
It apparently has some weaknesses if used on binary (non-text) data
but I don't see why it wouldn't work on Windows.
Well, when I mentioned 'difficulty to port to Windows', I was
referring to the number of references that the API may have to
This algorithm would be used for storage, but I could see potential
for needing improved security, as someone changing the pkg db in
memory could yield unwanted pkg installations or deletions, and just
unwanted pkg behavior in general from occurring thanks to some
malicious users..
Anyhow, thanks for the ideas I really do appreciate it. Overall, I
think I will stick with BDB's hash(3) (seems less data collision
prone, as was pointed out earlier, and less of a security risk) as I
wasn't aware of the NULL argument, no filename 'clause' with dbopen(3).
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
