| Current Path : /compat/linux/proc/68247/root/compat/linux/proc/68247/root/compat/linux/usr/share/doc/grep-2.5.1a/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //compat/linux/proc/68247/root/compat/linux/proc/68247/root/compat/linux/usr/share/doc/grep-2.5.1a/TODO |
Write Texinfo documentation for grep. The manual page would be a good place to start, but Info documents are also supposed to contain a tutorial and examples. Fix the DFA matcher to never use exponential space. (Fortunately, these cases are rare.) Improve the performance of the regex backtracking matcher. This matcher is agonizingly slow, and is responsible for grep sometimes being slower than Unix grep when backreferences are used. Provide support for the Posix [= =] and [. .] constructs. This is difficult because it requires locale-dependent details of the character set and collating sequence, but Posix does not standardize any method for accessing this information! ## Some test in tests/spencer2.tests should have failed !!! Need to filter out some bugs in dfa.[ch]/regex.[ch]. Threads for grep ? Grep does 32 bits arithmetic, it needs to move to 64. Clean up, to many #ifdef's !! Check some new Algorithms for matching, talk to Karl Berry and Nelson. Sunday's "Quick Search" Algorithm (CACM 33, 8 August 1990 pp. 132-142) claim that his algo. is faster then Boyer-More ???? Worth Checking. Take a look at cgrep (Context grep) seems like nice work. Take a look at sgrep (Struct grep). Take a look at agrep (Approximate grep), from glimpse. Can we merge ? POSIX Compliance see p10003.x Moving away from GNU regex API for POSIX regex API. Better and faster !!