From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/77464 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Debugger entered--Lisp error: (overflow-error "13419098521433281274") Date: Wed, 02 Mar 2011 14:17:14 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87aahdmg51.fsf@lifelogs.com> References: <87lj0x4k59.fsf@fastmail.fm> <87lj0x72ce.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299097123 6616 80.91.229.12 (2 Mar 2011 20:18:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2011 20:18:43 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M25787@lists.math.uh.edu Wed Mar 02 21:18:36 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PusVG-0003JV-3s for ding-account@gmane.org; Wed, 02 Mar 2011 21:18:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PusUT-000839-C5; Wed, 02 Mar 2011 14:17:45 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PusUQ-00082j-6F for ding@lists.math.uh.edu; Wed, 02 Mar 2011 14:17:42 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PusUN-0004yx-Su for ding@lists.math.uh.edu; Wed, 02 Mar 2011 14:17:41 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PusUL-0003mQ-Fk for ding@gnus.org; Wed, 02 Mar 2011 21:17:37 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PusUH-0002n4-FD for ding@gnus.org; Wed, 02 Mar 2011 21:17:33 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Mar 2011 21:17:33 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Mar 2011 21:17:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:A++tcmpChMq71Qv32/D9SksKNj4= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:77464 Archived-At: On Wed, 02 Mar 2011 20:24:17 +0100 Tassilo Horn 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