If I try to find some regular expression that contains
too many non-literal fields, I get a segmentation
fault. 28 seems to be some sort of magic number, at
least for \?. Here is how to repeat the bug:
echo -n 12345678901234567890123456 > testfile
joe testfile
find:
\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?
It says "Not found". Good.
echo -n 123456789012345678901234567 > testfile
joe testfile
find:
\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?
It says nothing. Not good, but at least it didn't crash.
echo -n 1234567890123456789012345678 > testfile
joe testfile
find:
\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?
It says "Segmentation fault". Very not good.
If I try \* instead, then it works with 28 \*'s, but
breaks with more. I didn't pin down a number. Similar
with \c or \[^\n]. A bunch of \\'s works fine.
joe:
** Joe's Own Editor v3.4 ** (ascii) ** Copyright (C)
2006 **
uname -s -r -v -m -p -i -o:
Linux 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC
2004 x86_64 x86_64 x86_64 GNU/Linux
gcc --version:
gcc (GCC) 3.3.3 (SuSE Linux)
Have fun,
Charles J. Tabony
Logged In: YES
user_id=1000448
The limit is 26. Look for [26] in regex.h if you want to
change this. I'll think about improving this for the next
version: I should really add \( and \) to allow the user to
select text to the be saved, or better switch pcre.
This is fixed with the new regex engine.