plugin: Don't do lossy shift on hash
authorNicolas Dufresne <nicolas.dufresne@collabora.com>
Fri, 13 Nov 2015 21:20:42 +0000 (16:20 -0500)
committerNicolas Dufresne <nicolas.dufresne@collabora.com>
Wed, 25 Nov 2015 19:26:11 +0000 (14:26 -0500)
commit446b3e6ddca7db6502745fc515560181a5c8b1fc
treee7490a01d155092a53258183ab5bcbb16bd1d27b
parent7e2aae7942f4232ee7a9e84c52d265b722890da3
plugin: Don't do lossy shift on hash

In plugin is responsible for calculating a hash of the dependencies
in order to determine if the cache should be invalidated or not.
Currently, the hash combining method removes a bit of the original
have before combining with an addition. As we use 32bits for our hash
and shift 1 bit for each file and directory, that resulting hash only
account for the last 32 files. And is more affected by the last file.

Rotating technique (shifting, and adding back the ending bit), can be
use to make the addition non-commutative. In a way that different order
gives different hashes. In this case, I don't preserve this behaviour
because the order in which the files are provided by the OS is
irrelevant.

In most cases, the XOR operation is used to combine hashes. In this
code we use the addition. I decided to preserve the addition because
we make use of non-random hash ((guint) -1) in the algorithm for
matching files that are not really part of the hash (symlinks, special
files). Doing successive XOR on this value, will simply switch from
full ones, to full zero. The XOR used with whitelist has been preserved
as it's based on a fairly randomized hash (g_str_hash).

https://bugzilla.gnome.org/show_bug.cgi?id=758078
gst/gstplugin.c