bug in tr ?

[Denys Vlasenko]

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[0]>arg[3])
> > 
> > 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?


And lastly:


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.
--
vda