From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/77463 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.gnus.general Subject: Re: Debugger entered--Lisp error: (overflow-error "13419098521433281274") Date: Wed, 02 Mar 2011 20:24:17 +0100 Message-ID: <87lj0x72ce.fsf@member.fsf.org> References: <87lj0x4k59.fsf@fastmail.fm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299093885 19884 80.91.229.12 (2 Mar 2011 19:24:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2011 19:24:45 +0000 (UTC) Cc: gnus mailing list To: Andreas Schwab Original-X-From: ding-owner+M25786@lists.math.uh.edu Wed Mar 02 20:24:39 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 1Purf4-0005ns-K6 for ding-account@gmane.org; Wed, 02 Mar 2011 20:24:39 +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 1Purer-0007pP-OH; Wed, 02 Mar 2011 13:24:25 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Purep-0007p7-Pu for ding@lists.math.uh.edu; Wed, 02 Mar 2011 13:24:23 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Pureo-0004Q4-5m for ding@lists.math.uh.edu; Wed, 02 Mar 2011 13:24:23 -0600 Original-Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Puren-0001hB-4f for ding@gnus.org; Wed, 02 Mar 2011 20:24:21 +0100 Original-Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 623E32041A; Wed, 2 Mar 2011 14:24:20 -0500 (EST) Original-Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 02 Mar 2011 14:24:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:cc:subject:references:date:in-reply-to:message-id:mime-version:content-type; s=smtpout; bh=BWTUMhk4OyUirjTqXAIXxl2qcog=; b=K6Vr0d04+R7C2ao5RrTnK9s4ebrRF2TUVrPDtyX0p55L8nuUr22sPvEWsr+UiEXiwnBG17ip3/jIqO2KhU6i92HyrkhUCWMT+z1GHbzyiM6r1C2oMppfaJ2rHgc3F4/wAj2rzoYgZh1Orh471neJOingbjdDakm7RpPwFpeutHw= X-Sasl-enc: ZYyR9Bj2Nwi5adje7IGGLRutiQeOuVRWHBucxW5/C0ON 1299093859 Original-Received: from thinkpad (95-88-32-105-dynip.superkabel.de [95.88.32.105]) by mail.messagingengine.com (Postfix) with ESMTPA id 01F35441646; Wed, 2 Mar 2011 14:24:18 -0500 (EST) In-Reply-To: (Andreas Schwab's message of "Wed, 02 Mar 2011 20:00:34 +0100") User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:77463 Archived-At: Andreas Schwab writes: >> But I'm still interested what that number actually means? > > This is an opaque (unsigned 64-bit) value updated by the server > whenever a metadata item is modified (RFC4551). That's a bit unfortunate. Today I've encountered 2 of these values that were too big to be `read' by emacs. Looking at `nnimap-parse-flags' I can see that the value of UIDVALIDITY is extracted by string-matching and stored as string, because it might be bigger than an emacs integer. Probably the same has to be done for the FETCH lines. Here's the offending code: --8<---------------cut here---------------start------------->8--- (while (re-search-forward "^\\* [0-9]+ FETCH " start t) (setq elems (read (current-buffer))) (push (cons (cadr (memq 'UID elems)) (cadr (memq 'FLAGS elems))) articles)) --8<---------------cut here---------------end--------------->8--- Of course, it is convenient to `read' the complete list in lines like * 2971 FETCH (FLAGS (%Recent) UID 12509 MODSEQ (13419098521433281274)) but it fails for large numbers. And if the RFC says those are 64bit unsigned ints, well, then Gnus has to handle those. Bye, Tassilo ...who wonders why he got this error twice today after using Gnus with IMAP servers (including that problematic one) for several years with no such issue at all...