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

Previous Next

Full log

Message #16 received at 24315 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: pok <at> netfonds.no (Peder O. Klingenberg)
Cc: 24315 <at> debbugs.gnu.org
Subject: Re: bug#24315: 25.1.50;
 re-search-forward errors with "Variable binding depth exceeds
 max-specpdl-size"
Date: Thu, 01 Sep 2016 21:58:36 -0400

pok <at> netfonds.no (Peder O. Klingenberg) writes:

> `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.

If it works without the regexp, that's even better.

> -it finds."
> +it finds. The current buffer should be an unfolded buffer as returned
            ^
Sentences should be double spaced.

> +from `icalendar--get-unfolded-buffer'."
>    (let (element children line name params param param-name param-value
>                  value
>                  (continue t))
> @@ -391,8 +392,8 @@ icalendar--read-element
>        (unless (looking-at ":")
>          (error "Oops"))
>        (forward-char 1)
> -      (re-search-forward  "\\(.*\\)\\(\r?\n[ \t].*\\)*" nil t)
> -      (setq value (icalendar--rris "\r?\n[ \t]" "" (match-string 0)))
> +      (setq value (buffer-substring (point) (line-end-position)))
> +      (end-of-line)

Might be better to avoid finding the end of line twice (since apparently
40k lines do happen, I guess it's worth thinking a bit about
optimizing):

(let ((start (prog1 (point) (end-of-line))))
  (setq value (buffer-substring start (point))))

Previous Next

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