Skip to content

lib.hash shortcomings (edge-cases) #332

@tmillr

Description

@tmillr

Note

This is a low-priority issue as these are edge-cases. I just want to report this here so that this is known (and before I forget).

  1. lib.hash does not sort table keys, which can lead to false cache-misses. The reason for this is that (to the best of my current knowledge) table key iteration order is not well-defined (or, in other words, is unspecified) in Lua. The effect is that two different tables (instances) with the same exact content can produce different hashes:
-- Here's just one example
local hash = require 'github-theme.lib.hash'
local function same() return { a = 1, b = 2, c = 3 } end
assert(hash({ a = 1, b = 2, c = 3 }) == hash(same())) -- fails!

local t = { b = 2 }
t.a = 1
rawset(t, 'c', 3)
assert(hash(same()) == hash(t))
assert(hash({ a = 1, b = 2, c = 3 }) == hash(t))

Edit: never-mind, the example above seems to be working for me now?


  1. lib.hash is not prefix-free, and suffers from prefix collisions (although in practice, given the expected content that we are hashing, these collisions are probably very unlikely). This can result in false cache-hits:
local hash = require 'github-theme.lib.hash'
assert(hash({ a = 'bc' }) ~= hash({ ab = 'c' })) -- fails!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions