bug in tr ?
vda.linux at googlemail.com
Mon Mar 16 06:23:46 UTC 2009
On Sunday 15 March 2009 19:26, walter harms wrote:
> Denys Vlasenko schrieb:
> > On Sunday 15 March 2009 16:47, walter harms wrote:
> >>> Try attached patch, it fixes all these problems in my testing.
> >> I have tested the patch and it seems to work ok.
> >> [:xdigit:] seems to work
> >> While testing i noticed that tr -dc [z-A] behaver differs from GNU tr
> >> GNU:
> >> tr -dc [z-A]
> >> tr: range-endpoints of `z-A' are in reverse collating sequence order
> >> therefor i suggest a patch like that:
> >> --- coreutils/tr.c.org 2009-03-15 16:07:41.000000000 +0100
> >> +++ coreutils/tr.c 2009-03-15 16:14:06.000000000 +0100
> >> @@ -62,6 +62,9 @@
> >> continue; /* next iter will copy '-' and stop */
> >> }
> >> i = *arg;
> >> + if (arg>arg)
> > arg is "const char *arg". Bug above if char type is signed.
> > Also, I suspect no one has scripts which depend on
> > that "tr z-A" fails, that would be strange.
> yep, but the point is that GNU tr fails while bb tr works.
> I still suggest add the check (with casting) to have the same behaver.
This would enlarge the binary, therefore - how is this useful?
"tr z-A" now works, it will start to fail. This will match
GNU tr, yes, but do you REALLY think there are people who deliberately
run GNU tr with command line "tr z-A" and REQUIRE it to fail?
Why anyone would do that?
TR(P) POSIX Programmer's Manual TR(P)
c-c In the POSIX locale, this construct shall represent the range of
collating elements between the range endpoints (as long as nei-
ther endpoint is an octal sequence of the form \octal), inclu-
sive, as defined by the collation sequence. The characters or
collating elements in the range shall be placed in the array in
ascending collation sequence. If the second endpoint precedes
the starting endpoint in the collation sequence, it is unspeci-
fied whether the range of collating elements is empty, or this
construct is treated as invalid. In locales other than the POSIX
locale, this construct has unspecified behavior.
we don't violate POSIX.
More information about the busybox