Re: Debugger entered--Lisp error: (overflow-error "13419098521433281274")

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 02 Mar 2011 20:24:17 +0100 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> That's a bit unfortunate.  Today I've encountered 2 of these values that
TH> were too big to be `read' by emacs.

TH> Looking at `nnimap-parse-flags' I can see that the value of UIDVALIDITY
TH> is extracted by string-matching and stored as string, because it might
TH> be bigger than an emacs integer.  Probably the same has to be done for
TH> the FETCH lines.

TH> Here's the offending code:
TH> 	  (while (re-search-forward "^\\* [0-9]+ FETCH " start t)
TH> 	    (setq elems (read (current-buffer)))
TH> 	    (push (cons (cadr (memq 'UID elems))
TH> 			(cadr (memq 'FLAGS elems)))
TH> 		  articles))

TH> Of course, it is convenient to `read' the complete list in lines like

TH>   * 2971 FETCH (FLAGS (%Recent) UID 12509 MODSEQ (13419098521433281274))

TH> but it fails for large numbers.  And if the RFC says those are 64bit
TH> unsigned ints, well, then Gnus has to handle those.

Gnus has no way to do it when Emacs can't.  The calc package has some
facilities for big numbers but yeah, (read) will not DTRT with input
like that.  I've asked for it on emacs-devel.

To fix it now, I would replace such large numbers with a truncated
version, which can be done safely with a regex before the reader sees
the input.  But I'll let Lars decide, he knows that code best.

Ted