# [PATCH] FNV-1 support for ext/hash - Thread: https://externals.io/message/47519 - Original archive: https://news-web.php.net/php.internals/47519 - Started by Michael Maclean on 2010-03-23T22:01:20+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47519 — Michael Maclean — 2010-03-23T22:01:20+00:00 URL: https://externals.io/message/47519#47519 Hi, A while back I wrote a patch for ext/hash to add support for the 32- and 64-bit variants of the FNV-1 hash algorithm. Since we now have a new trunk, I thought I'd clean it up a bit, and thanks to some suggestions from Pierre and Johannes on IRC it's a bit better now. Would anyone object to applying this to trunk (and could someone do it for me, as I have no karma for that)? Description of the algorithm: http://www.isthe.com/chongo/tech/comp/fnv/index.html http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function The patch: http://mgdm.net/~michael/patches/php-fnv.txt -- Cheers, Michael --- ## #47524 — Derick Rethans — 2010-03-23T22:08:33+00:00 URL: https://externals.io/message/47519#47524 · In reply to: #47519 > A while back I wrote a patch for ext/hash to add support for the 32- and > 64-bit variants of the FNV-1 hash algorithm. Since we now have a new trunk, I > thought I'd clean it up a bit, and thanks to some suggestions from Pierre and > Johannes on IRC it's a bit better now. Would anyone object to applying this to > trunk (and could someone do it for me, as I have no karma for that)? You do have karma; looks great! with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47531 — sean finney — 2010-03-23T22:41:06+00:00 URL: https://externals.io/message/47519#47531 · In reply to: #47519 > The patch: > http://mgdm.net/~michael/patches/php-fnv.txt just to throw something out there, shouldn't the various inputLen parameters be of type size_t instead of unsigned int? sean --- ## #47535 — Michael Maclean — 2010-03-23T23:18:09+00:00 URL: https://externals.io/message/47519#47535 · In reply to: #47531 sean finney wrote: > > > […] > > just to throw something out there, shouldn't the various inputLen > parameters be of type size_t instead of unsigned int? The function signature in php_hash.g says unsigned int, so that's what I used (though I note some of the other algorithms appear not to). We don't support files > 2^32 on 64-bit, so as I understand it, it's not going to cause issues right now, but if a large file support patch lands it's something that I might revisit. -- Cheers, Michael --- ## #47536 — Michael Maclean — 2010-03-23T23:31:05+00:00 URL: https://externals.io/message/47519#47536 · In reply to: #47535 Michael Maclean wrote: > The function signature in php_hash.g says unsigned int, so that's what I > used (though I note some of the other algorithms appear not to). We > don't support files > 2^32 on 64-bit, so as I understand it, it's not > going to cause issues right now, but if a large file support patch lands > it's something that I might revisit. > And of course, when I say "file" here, I mean "string". Ahem. -- Cheers, Michael --- ## #47544 — sean finney — 2010-03-24T06:48:52+00:00 URL: https://externals.io/message/47519#47544 · In reply to: #47535 > > […] > > The function signature in php_hash.g says unsigned int, so that's > what I used (though I note some of the other algorithms appear not > to). We don't support files > 2^32 on 64-bit, so as I understand it, > it's not going to cause issues right now, but if a large file > support patch lands it's something that I might revisit. okay, so the hash module is generally broken for files > 2GB? didn't know that. i see update functions using both uint and size_t, but the function pointer signature uses uint so i doubt the hash results would be correct. sean --- ## #47550 — Pierre Joye — 2010-03-24T09:26:45+00:00 URL: https://externals.io/message/47519#47550 · In reply to: #47544 hi Sean, > okay, so the hash module is generally broken for files > 2GB?  didn't > know that.  i see update functions using both uint and size_t, but the > function pointer signature uses uint so i doubt the hash results would > be correct. As far as I can tell that's not only for the hash module. Many areas in php and its libraries rely on (u)int instead of size_t. It is or was a common mistake. The problem is to change the signature now without breaking ABI. That's something we could fix in trunk. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47575 — sean finney — 2010-03-24T18:04:50+00:00 URL: https://externals.io/message/47519#47575 · In reply to: #47550 > As far as I can tell that's not only for the hash module. Many areas > in php and its libraries rely on (u)int instead of size_t. It is or > was a common mistake. The problem is to change the signature now > without breaking ABI. > > That's something we could fix in trunk. yeah, i only brought it up because it was new code being proposed, and no reason to have yet another undocumented place where this needed to be fixed. but, it seems from further info that the hash functions are used elsewhere in the module in such a way that the parameter ends up treated as a uint no matter what, so i don't think there's much to be done without tackling the larger problem. so, sorry for the noise :) sean