The human-sort from paradakh

Incorrect behavior

These should both output Less:

dbg!(human_sort::compare("x101", "x1000"));
dbg!(human_sort::compare("x101", "x2000"));

But,

human_sort::compare("x101", "x1000") = Greater
human_sort::compare("x101", "x2000") = Less

This happens because digits are consumed normally if they are equal, and only on the first differing digits, is the number comparison routine started.

panic (with long hex strings(?))

Happens with human_sort 0.2.2 (140a09c9305e6d5e557e2ed7cbc68e05765a7d4213975b87cb04920689cc6219).

To reproduce:

fn main() {
    use human_sort::sort;
    let mut arr = [
        "PowerTools/x86_64/os/repodata/9379911671413f8a51cd04665cd9bafc8200f927505008e8a11145034b53c776-other.xml.gz",
        "PowerTools/x86_64/os/repodata/43ed191200dbc7c83be76c3410f118f931bbe21ff6a58f5f549d0e351f3aea94-other.sqlite.xz",
    ];
    sort(&mut arr);
}

$ env RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/humansortcrash`
thread 'main' panicked at 'attempt to multiply with overflow', /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:94:23
stack backtrace:
  ...
  13: core::panicking::panic
             at src/libcore/panicking.rs:50
  14: human_sort::take_numeric
             at /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:94
  15: human_sort::compare_chars_iters
             at /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:76
  16: human_sort::compare
             at /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:59
  17: human_sort::sort::{{closure}}
             at /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:44
  18: alloc::slice::<impl [T]>::sort_by::{{closure}}
             at /build/rust/src/rustc-1.46.0-src/src/liballoc/slice.rs:252
  19: alloc::slice::insert_head
             at /build/rust/src/rustc-1.46.0-src/src/liballoc/slice.rs:759
  20: alloc::slice::merge_sort
             at /build/rust/src/rustc-1.46.0-src/src/liballoc/slice.rs:966
  21: alloc::slice::<impl [T]>::sort_by
             at /build/rust/src/rustc-1.46.0-src/src/liballoc/slice.rs:252
  22: human_sort::sort
             at /home/julius/.cargo/registry/src/github.com-1ecc6299db9ec823/human-sort-0.2.2/src/lib.rs:44
  23: humansortcrash::main
             at src/main.rs:7
  ...

I'm guessing it's the long hex strings (hashes, I guess). I encountered them in the wild.

Feature request: case-insensitive sorting

Currently, human-sort is case sensitive. This means that we need to call to_lowercase on the inputs if we want to sort while ignoring case, which wastes some time and needs to heap-allocate memory. These performance hits are unnecessary since char::eq_ignore_ascii_case exists, but unfortunately the human-sort API is not flexible enough to let us specify sorting options.

It would be nice if we could, as a first step, have a [compare/sort]_case_insensitive function.

paradakh / human-sort Goto Github PK

human-sort's People

Contributors

Stargazers

Watchers

Forkers

human-sort's Issues

Incorrect behavior

panic (with long hex strings(?))

Feature request: case-insensitive sorting

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent