https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247494
--- Comment #5 from Conrad Meyer <c...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
