[Bug 247494] sort(1) order affected by LC_CTYPE

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247494

--- Comment #5 from Conrad Meyer <cem at 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.