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

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

[debbugs-tracker] bug#33083: closed (27.0.50; Bignums and message-checks


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#33083: closed (27.0.50; Bignums and message-checksum)
Date: Wed, 26 Dec 2018 09:18:02 +0000

Your message dated Wed, 26 Dec 2018 01:17:04 -0800
with message-id <address@hidden>
and subject line 27.0.50; Bignums and message-checksum
has caused the debbugs.gnu.org bug report #33083,
regarding 27.0.50; Bignums and message-checksum
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
33083: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33083
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 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



--- End Message ---
--- Begin Message --- Subject: 27.0.50; Bignums and message-checksum Date: Wed, 26 Dec 2018 01:17:04 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Thanks for reporting the bug. I installed the attached, which is a conservative patch that should fix the bug, though it doesn't address the more-general issues that you mentioned.

Attachment: 0001-Port-message-checksum-to-bignums.patch
Description: Text Data


--- End Message ---

reply via email to

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