/usr/share/doc/crm114/KNOWNBUGS.txt is in crm114 20100106-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 | #
# knownbugs.txt - CRM114 Known Bugs
#
# Copyright 2001-2009 William S. Yerazunis.
# This file is under GPLv3, as described in COPYING.
CRM114 Known Bugs:
1) (fixed)
2) Matcher bug... This bug is in the GNU library, not my code. If you
match on a window longer than 20479 characters, AND you have multiline
matching enabled, AND the pattern is of the form ".*literalvale", then
the match will FAIL even if it should have succeeded. The TRE library
does not have this bug. (see "make experimental")
(FIXED - default library is now TRE 0.7.4)
3) Matcher bug - this is another bug in the GNU regex library. If you
have a pattern of the form ^Q$ where Q is a single character, and you
don't specify <nomultiline>, then the match will mysteriously fail even
if it should have succeeded. The TRE regex library does not have this
problem (see "make experimental").
(FIXED - default library is now TRE 0.7.4)
3+) More on bug 3 - it seems that _many_ patterns of the form ^blah$
do not work correctly, including the simple case for a null string of
^$ even if you _do_ specify nomultiline. The TRE regex library does
not have this problem either.
(FIXED - default library is now TRE 0.7.4)
3++) The GNU regex engine considers /./ to match not only the
string "a", but also the empty string "". This is in contrast
to /../ which does match "aa" but not "a".
(FIXED - default library is now TRE 0.7.4)
4) Thinking bug... If you ALTER one variable that contains another
variable, the second variable moves as though you inserted/deleted
charactes at the START of the first variable, and then overtyped
all of the evenly matched characters. This can lead to
counterintuitive results; the fix is to ISOLATE any variable that
has to hold value across an ALTER operation.
(FIXED - default library is now TRE 0.7.4)
5) FIXED AT LONG LAST (version 20040815) Memory leak - if you MATCH to
bind a var, then ISOLATE that var, then MATCH it again, the old
ISOLATEd usage is _not_ recovered. If you do this enough, you will
run out of buffer space and get a FATAL ERROR.
The quick workaround is to use two variables- for example, :a: and
:isolated_a: as shown here:
match :a:
isolate (:isolated_a:) /:*:a:/
match (:a:)
isolate (:isolated_a:) /:*:a:/
ad infinitum, which will _not_ leak memory.
(REAL FIX in by 20060629 - off by one error in line 920
of crm_var_hash_table.c)
6) If you do math, and the output is bigger than a trillion or less than
1 trillionth, the output comes out in E-notation.
This is fine -except that you can't _re_use that, because the numerical
parser doesn't understand E-notation.
Be warned. Or send me a patch!
(FIXED - the switchover between fixed and E notation is now
a soft set, and the reader DOES understand E-notation)
7) If you malform a math expression (like leave off the closing colon)
the last digit of your result gets eaten.
e.g.:
/:@: 1 + 123 :/ --> 124 (correct)
/:@: 1 + 123 / --> 12 (incorrect)
Patches appreciated on this one too.
( SEMI-FIXED - you now get an error that says "you didn't end with
an ':', which is often an error. However, it still gets the wrong
result. )
Let me know if you find any others!
-Bill Y.
|