bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33083: 27.0.50; Bignums and message-checksum


From: Stefan Monnier
Subject: bug#33083: 27.0.50; Bignums and message-checksum
Date: Thu, 18 Oct 2018 10:55:36 -0400

Package: Emacs
Version: 27.0.50

I just got this error:

    Debugger entered--Lisp error: (overflow-error)
      ash(100.....0170 1)
      message-checksum()
      message--yank-original-internal(nil)
      (let nil (message--yank-original-internal 'nil))
      eval((let nil (message--yank-original-internal 'nil)))
      message-yank-original()
      [...]
      command-execute(gnus-summary-followup-with-original)

Where the "....." is fairly long.  The problem is simple:
In message-checksum we do

      (while (not (eobp))
        (when (not (looking-at "[ \t\n]"))
          (setq sum (logxor (ash sum 1) (if (natnump sum) 0 1)
                            (char-after))))
        (forward-char 1)))

where the code assumes an `ash` where the MSB bit would overflow into
the sign bit when the result can't fit in a fixnum, and the (if (natnump
sum) 0 1) ends up feeding that sign bit back to the LSB, thus doing
a "rotate".

Of course, with bignums we don't overflow until we reach the 65536 bits
and when we do, we signal an error instead of dropping the extra bits.

So the above error is signaled when the yanked text is longer than 20Kchars
(or non-whitespace chars).  Note that even before we reach this error,
we have another problem: this function is basically used at one spot
where we do

      (not (eq (message-checksum) message-checksum))

and if the checksum is larger than a fixnum, then this `eq` will always
return false even if both numbers are equal.

So, ever since we switched to bignums, this equality is basically always
false (except when yanking less 8 non-whitespace chars).

What should we do:
- just get rid of this message-checksum feature (which has been broken
  in master for a few months now).
- replace message-checksum with something like md5 (which will be faster
  but won't ignore whitespace chars like the current code does).
- try to get back the original semantics (e.g. by introducing a proper
  bit-rotate primitive).


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]