Date: Tue, 23 Jun 2020 15:40:09 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 247494] sort(1) order affected by LC_CTYPE Message-ID: <bug-247494-227-Ceh3pP26EZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-247494-227@https.bugs.freebsd.org/bugzilla/> References: <bug-247494-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247494 --- Comment #5 from Conrad Meyer <cem@freebsd.org> --- Hm we actually do bucket same-byte values in add_to_sublevel. Why do we call strcmp eventually? ah: 379 default: 380 if (TINY_NODE(sl) || (sl->level > 15)) { 381 listcoll_t func; 382 383 func = get_list_call_func(sl->level); ( == list_coll_offset(,, sl->level)) ... 385 sl->leaves = sl->tosort; 386 sl->leaves_num = sl->tosort_num; 387 sl->leaves_sz = sl->leaves_num; ... 403 DEFAULT_SORT_FUNC_RADIXSORT(sl->leaves, sl->leaves_num, 404 sizeof(struct sort_list_item *), 405 (int(*)(const void *, const void *)) func); This appears to be a fast path when sorting a relatively small number of strings (< 65), or a degenerate case for comparing string bytes beyond 15 bytes. When I input 100 1-wchar strings to radixsort, it attempts to radix sort, but does so incorrectly. So there are several bugs: 1. radixsort does not process wchar strings correctly. 2. radixsort's fastpath does not invoke collate correctly for wchar strings. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247494-227-Ceh3pP26EZ>