Bug 147567

Summary: sort -t mb handling broken -- affects LSB 1.3 conformance
Product: Red Hat Enterprise Linux 4 Reporter: Jakub Jelinek <jakub>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: ezannoni, llim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-194 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-09 12:06:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 137160, 142941, 145007, 158752    
Attachments:
Description Flags
Patch to fix the bug none

Description Jakub Jelinek 2005-02-09 12:52:22 UTC 
sort -t handling with MB_CUR_MAX > 1 is very broken in several ways.
One problem shows up e.g. in LSB 1.3 testsuite on big endian platforms, where
10|567 /tset/LI18NUX2K.L1/utils/sort/sort 18:32:15|TC Start, scenario ref 571-0
520|567 8 23535 1 1|* When -t option is specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 8 23535 1 2|
520|567 8 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 8 1 18:32:21|FAIL
520|567 24 23535 1 1|* When -c and -t option are specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 24 23535 1 2|
520|567 24 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 24 1 18:32:29|FAIL
520|567 40 23535 1 1|* When -m and -t option are specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 40 23535 1 2|
520|567 40 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 40 1 18:32:36|FAIL

But as shown in the attached testcase, it is not just big endian platforms that
have -t broken.

I wonder why this was missed during RHEL3 LSB testing.
Comment 1 Jakub Jelinek 2005-02-09 12:52:23 UTC 
Created attachment 110864 [details]
Patch to fix the bug
Comment 2 Jakub Jelinek 2005-02-09 12:55:46 UTC 
Affects FC3/FC4 as well and likely (but untested) RHEL3 too.
Comment 3 Jakub Jelinek 2005-02-09 12:58:33 UTC 
*** Bug 147568 has been marked as a duplicate of this bug. ***
Comment 4 Tim Waugh 2005-02-09 15:12:30 UTC 
Thanks.  5.2.1-41 built in devel.
Comment 5 Tim Waugh 2005-02-09 16:52:28 UTC 
Committed to CVS in RHEL-4.
Comment 6 Tim Waugh 2005-02-09 17:45:41 UTC 
While porting to RHEL-3 I found that the sort-mb-tests already pass without any
changes to sort.c, beyond what's already in CVS.
Comment 7 Jakub Jelinek 2005-02-09 21:50:08 UTC 
Looking at RHEL3 coreutils-i18n.patch this is no wonder to me.
+static unsigned char tab[MB_LEN_MAX + 1];
tab has been a char array, not int as in RHEL4, etc.
From what I can see, RHEL4 sort against RHEL3 sort (in both cases without
i18n patch) added -t '\0' handling and error for -t a -t b and the former
caused int tab;.
Comment 8 Elena Zannoni 2005-02-18 17:33:37 UTC 
Can this be put in modified?
Comment 9 Tim Waugh 2005-02-18 18:03:25 UTC 
No, it hasn't been built for RHEL4.

Should it be built for RHEL4?  If so, targetting which update release?
Comment 10 Elena Zannoni 2005-02-18 18:15:06 UTC 
update 1, since we are targetting LSB compliance with that update.
Comment 13 Tim Powers 2005-06-09 12:06:14 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-194.html