From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/78855 Path: news.gmane.org!not-for-mail From: Matthias Andree Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Match lone lines in imap efficiently Date: Thu, 19 May 2011 10:55:41 +0200 Message-ID: <4DD4DB0D.7050307@gmx.de> References: <1305767995-27472-1-git-send-email-wenrui@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1305795360 9409 80.91.229.12 (19 May 2011 08:56:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 May 2011 08:56:00 +0000 (UTC) Cc: ding@gnus.org To: Roger Original-X-From: ding-owner+M27155=ding+2Daccount=gmane.org@lists.math.uh.edu Thu May 19 10:55:55 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 1QMz1P-0008B6-DB for ding-account@gmane.org; Thu, 19 May 2011 10:55:55 +0200 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 1QMz1N-0007Oh-RI for ding-account@gmane.org; Thu, 19 May 2011 03:55:53 -0500 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 1QMz1M-0007Oa-8z for ding@lists.math.uh.edu; Thu, 19 May 2011 03:55:52 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QMz1K-0004w3-OC for ding@lists.math.uh.edu; Thu, 19 May 2011 03:55:51 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]) by quimby.gnus.org with smtp (Exim 4.72) (envelope-from ) id 1QMz1I-0003Jk-FS for ding@gnus.org; Thu, 19 May 2011 10:55:48 +0200 Original-Received: (qmail invoked by alias); 19 May 2011 08:55:42 -0000 Original-Received: from f055056009.adsl.alicedsl.de (EHLO apollo.emma.line.org) [78.55.56.9] by mail.gmx.net (mp069) with SMTP; 19 May 2011 10:55:42 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX183MTsTxVA39X9XygSAWoPg0SEeSP4gaPm+MZ4ZKN PbILlY6kiCxADb Original-Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5BBFF23D354; Thu, 19 May 2011 10:55:41 +0200 (CEST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Mnenhy/0.8.3 Thunderbird/3.1.10 In-Reply-To: <1305767995-27472-1-git-send-email-wenrui@gmail.com> X-Enigmail-Version: 1.1.2 X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:78855 Archived-At: Am 19.05.2011 03:19, schrieb Roger: > When some email with large number of recipients is hit, Gnus > will hit error "Stack overflow in regexp matcher" > --- > lisp/nnimap.el | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lisp/nnimap.el b/lisp/nnimap.el > index 6882ed6..967cb36 100644 > --- a/lisp/nnimap.el > +++ b/lisp/nnimap.el > @@ -190,7 +190,7 @@ textual parts.") > (let (article bytes lines size string) > (block nil > (while (not (eobp)) > - (while (not (looking-at "^\\* [0-9]+ FETCH.*UID \\([0-9]+\\)")) > + (while (not (looking-at "^\\* [0-9]+ FETCH[[:space:](]*UID \\([0-9]+\\)")) > (delete-region (point) (progn (forward-line 1) (point))) > (when (eobp) > (return))) > @@ -1904,7 +1904,7 @@ textual parts.") > (let (article bytes) > (block nil > (while (not (eobp)) > - (while (not (looking-at "^\\* [0-9]+ FETCH.*UID \\([0-9]+\\)")) > + (while (not (looking-at "^\\* [0-9]+ FETCH[[:space:](]*UID \\([0-9]+\\)")) > (delete-region (point) (progn (forward-line 1) (point))) > (when (eobp) > (return))) While it may fix the immediate problem, it looks pretty bogus to me and will break IMAP functionality with some servers, depending on response format. I think dumb regexps aren't the right approach for IMAP parsing, instead, the reply should be properly parsed into keywords. 1. RFC3501 demands that there is exactly one SP between the FETCH keyword and the sequence set. 2. The open parenthesis isn't optional before UID - it must be somewhere between FETCH and UID. 3. Other keywords can come before the UID, see p. 61 in RFC3501. Your patch breaks that.