diff options
author | Joey Hess <joey@gnu.kitenet.net> | 2009-03-08 18:46:18 -0400 |
---|---|---|
committer | Joey Hess <joey@gnu.kitenet.net> | 2009-03-08 18:49:34 -0400 |
commit | d3b4c2dbd13f6721042db7a7b6843851c9037551 (patch) | |
tree | 217212203e3eaa09f0bf2b4dca8b2e49d175be1e /doc/bugs/Links_with_symbols_can__39__t_be_edited.mdwn | |
parent | 1edad6dca70175fd44b4f2e4e3bd8b3b16bbc055 (diff) |
avoid potential infinite loop in smiley expansion
- In 3.05, ikiwiki began expanding templates in scan mode,
for annoying, expensive, but ultimatly necessary reasons
of correctness.
- Smiley processing has a bug: It inserts a span for the smiley,
and then continues searching forward in the content for more,
starting at $end_of_smiley+1. Which means it searches for smilies
in the span too! And if it somehow finds one, we get an infinite loop
here.
- This bug can, probably, only be tickled if a htmllink to
show the smiley fails, because the smiley file doesn't exist,
or because ikiwiki doesn't know about it. In that case,
a link will be inserted to _create_ the missing page,
and that link will include the smiley inside the <a></a>.
- When a template is expanded in scan mode, and it contains
an inline, the sanitize hook is run during scan mode,
which never happened before. That causes the smiley processor
to run, before ikiwiki is, necessarily, aware that all
the smiley files exist (depending on scan order). So
it inserts creation links for them, and triggers the bug.
I've put in the simple fix of jumping forward past the inserted
span, and it does fix the problem. I will need to look in a bit
more detail into why an inline nested inside a template is
fully expanded during the scan pass -- that really shouldn't
be necessary, and it makes things much slower than they need
to be.
Diffstat (limited to 'doc/bugs/Links_with_symbols_can__39__t_be_edited.mdwn')
0 files changed, 0 insertions, 0 deletions