Some of my elisp code broke down when I ran it on a newer emacs because
the values returned by sxhash are different from what they were in the
old version.

I had assumed without thinking that sxhash'es of Lisp objects were fixed
one and for all, a bit like the shasum of some file.

Probably the doc string should be more explicit about what is/is not
guaranteed. Is consistency only guaranteed inside the current running
emacs thread/process?


Looking at the source code in src/fns.c, it seems that the change of
sxhash values was caused by the recent change allowing emacs lisp
integers of arbitrary size. These numbers are hashed differently, and
hashing itself has to truncate large integers that are now a different
data type. (However, I have also found changes in sxhash values between
v26.1 and v26.2, before the move to arbitrary large integers in v27, see
examples below.)

Looking at the source code, one would think that sxhash values are meant
to only depend on the structure of the Lisp object itself, not the
hardware or the emacs version, but of course this view may have to yield
when the C data type for Lisp objects is modified. Is this what the
developers had in mind?


Today the elisp manual reads

— Function: *sxhash-equal*obj

    This function returns a hash code for Lisp object obj. This is an
    integer which reflects the contents of obj and the other Lisp
    objects it points to.

    If two objects obj1 and obj2 are |equal|, then |(sxhash-equal
    |obj1|)| and |(sxhash-equal |obj2|)| are the same integer.

    If the two objects are not |equal|, the values returned by
    |sxhash-equal| are usually different, but not always; once in a rare
    while, by luck, you will encounter two distinct-looking objects that
    give the same result from |sxhash-equal|.

This does not address the consistency issue, and is a bit misleading
about collisions with its "once in a rare while, by luck".  Without
trying, I stumbled upon many collisions in my test. Is sxhash really
intended to avoid collisions?

Many thanks for your time,

--philippe


Here is what I obtained by running emacs -Q --batch -l  sxhash-report.el
(.el file attached below) on 3 different versions of emacs:

in GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.6.0, NS appkit-1671.50
Version 10.14.5 (Build 18F132))
 of 2019-05-28
1 is hash for 1
0 is hash for 0
0 is hash for nil
11484 is hash for t
0 is hash for (0 . 0)
0 is hash for ""
2030 is hash for "ab"
517809 is hash for "abcd"
93076 is hash for (1 2 3 4 5)
1608904915 is hash for (a b c)
5457926 is hash for ab
5457938 is hash for abcd
5457950 is hash for :misc

in GNU Emacs 26.2 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20
Version 10.14.3 (Build 18D109))
 of 2019-04-13
1 is hash for 1
0 is hash for 0
0 is hash for nil
11616 is hash for t
0 is hash for (0 . 0)
0 is hash for ""
2030 is hash for "ab"
517809 is hash for "abcd"
93076 is hash for (1 2 3 4 5)
6307170282 is hash for (a b c)
10938216 is hash for ab
10938228 is hash for abcd
10938240 is hash for :misc

in GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.6.0, NS
appkit-1671.50 Version 10.14.5 (Build 18F132))
 of 2019-06-06
1 is hash for 1
0 is hash for 0
0 is hash for nil
11784 is hash for t
0 is hash for (0 . 0)
0 is hash for ""
2030 is hash for "ab"
517809 is hash for "abcd"
93076 is hash for (1 2 3 4 5)
238969789 is hash for (a b c)
35167434275996 is hash for ab
35167434276008 is hash for abcd
35167434276020 is hash for :misc