From f215027fd420468f793743ef8729701f25554b34 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Fri, 20 Nov 2020 00:38:41 -0600 Subject: [PATCH] Switched to CRC as seed collection function instead of xor As noted by gtaska, we are sitting on a better hash-combining function than xor: CRC. Previous issues with xor were solvable, but relying on xor for this isn't really worth the risk when we already have a CRC function readily available. To quote a study found by gtaska: https://michiel.buddingh.eu/distribution-of-hash-values > CRC32 seems to score really well, but its graph is skewed by the results > of Dataset 5 (binary numbers), which may or may not be too synthetic to > be considered a fair benchmark. But even if you substract the results > from that test, it does not fare significantly worse than other, > cryptographic hash functions. --- lfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lfs.c b/lfs.c index cc8ca38..4521064 100644 --- a/lfs.c +++ b/lfs.c @@ -872,8 +872,10 @@ static lfs_stag_t lfs_dir_fetchmatch(lfs_t *lfs, ptag ^= (lfs_tag_t)(lfs_tag_chunk(tag) & 1U) << 31; // toss our crc into the filesystem seed for - // pseudorandom numbers - lfs->seed ^= crc; + // pseudorandom numbers, note we use another crc here + // as a collection function because it is sufficiently + // random and convenient + lfs->seed = lfs_crc(lfs->seed, &crc, sizeof(crc)); // update with what's found so far besttag = tempbesttag;