GNU bug report logs - #24315
icalendar--read-element uses inefficient regexp

Previous Next

Full log

View this message in rfc822 format

From: pok <at> netfonds.no (Peder O. Klingenberg)
To: npostavs <at> users.sourceforge.net
Cc: 24315 <at> debbugs.gnu.org
Subject: bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size"
Date: Tue, 30 Aug 2016 15:09:34 +0200

[Message part 1 (text/plain, inline)]

On Fri, Aug 26 2016 at 23:35, npostavs <at> users.sourceforge.net wrote:

> This looks like it would be an inefficient regexp, since it has nested
> stars.  I suspect searching for "^[ \t]" multiple times would be more
> efficient than trying to match multiple lines in a single regexp.

Tried that.  It sort of worked, in that it worked when I directly called
`icalendar--read-event' in a buffer containing the event as manually
extracted from the gnus message.

However, parsing the problematic message in gnus still failed.  It turns
out `gnus-icalendar-event-from-buffer' calls
`icalendar--get-unfolded-buffer' before `icalendar--read-event'.

`icalendar--get-unfolded-buffer' takes care of all those pesky line
continuations, and returns a buffer with each element occupying exactly
one line.  So essentially `icalendar--read-event' was using a regexp to
extract the rest of the line, and that failed with a line nearly 40k
characters long.

The only other in-tree caller of `icalendar--read-event' (excluding
itself) also calls `icalendar--get-unfolded-buffer' first, and indeed,
`icalendar-read-event' already relies on this to take care of line
continuations in element parameters (as opposed to values).

Attached is a patch that uses buffer-substring to accomplish the same
thing as the offending regexp, and documents the dependency on
`icalendar--get-unfolded-buffer'.  This fixes the problem for me.

[bug24315.patch (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.