>Number: 150384
>Category: bin
>Synopsis: tr mis-parses '[=]=]' equivalence class
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Sep 08 12:30:00 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Richard Lowe
>Release: CURRENT
>Organization:
>Environment:
N/A
>Description:
While working on porting the FreeBSD tr(1) to another system, we hit upon an
issue reported by a user that tr didn't process '[=]=]' in the way they
expected, that is:
echo '[[[[]]]]' | tr -d '[=]=]'
Would print an empty string, rather than '[[[['
It seems that in bracket(), tr parses the above equivalence class as a
character class, '[=]' followed by '=]', due to the call to strchr() finding
the central ] when searching for a terminator then finding that the length of
the class is less than 4, and punting on it.
>How-To-Repeat:
echo "[[[[]]]]" | tr -d '[=]=]'
Expecting '[[[['
>Fix:
A naive patch, causing bracket() to skip an extra character (that forming the
equivalence class) before searching for the terminating ']', is attached.
Patch attached with submission follows:
diff -u /home/richlowe/str.c /tmp/buffer-content-1887OIZ
--- /home/richlowe/str.c 2010-09-08 08:13:18.000000000 -0400
+++ /tmp/buffer-content-1887OIZ 2010-09-08 08:17:36.000000000 -0400
@@ -156,7 +156,7 @@
s->str = p + 1;
return (1);
case '=': /* "[=equiv=]" */
- if ((p = strchr(s->str + 2, ']')) == NULL)
+ if ((p = strchr(s->str + 3, ']')) == NULL)
return (0);
if (*(p - 1) != '=' || p - s->str < 4)
goto repeat;
Diff finished. Wed Sep 8 08:17:36 2010
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
