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

[Andreas Schwab <schwab@linux-m68k.org>]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
> Hi Ted,
>
>> 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.
>
> But that huge number is not used by gnus, anyway.  It is `read' but only
> the UID and FLAGS values are saved.  So IMHO, the proper fix is to put a
> condition-case around the `read' that picks the UID and FLAGS with
> string-matching if an overflow-error occurs.

That won't work since you won't be able to read the rest either (since
it is read as a single sexp).  A possible fix would be to insert a space
into the middle of any number sequence that is longer than 9 digits.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."