Re: [PATCH] Match lone lines in imap efficiently

[Matthias Andree <matthias.andree@gmx.de>]

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.