Potential unsound public API

[charlesxsh]

Except the issues mentioned at #37,
At src/common.rs:76

    pub fn check_len(&self, n: usize) -> bool {
        unsafe { self.ptr.add(n) <= self.end }
    }

The index does have appropriate check and passed into pointer's add, which violates the safety requirements mentioned in document

Suggestion:

1. use self.end minus self.ptr frist

[Alexhuszagh]

This crate unfortunately is unmaintained right now and these issues are documented extensively in the RUSTSEC advisory
https://rustsec.org/advisories/RUSTSEC-2024-0379.html

Hopefully a new version will be published.

[charlesxsh]

Thanks for the confirm and reply! I found thoese issues during the tool scanning as well and simply make a note for another issue not mentioned in the discussion.

[tisonkun]

@Alexhuszagh since rust-lang/rust#86761 brings most of fast-float code into Rust's std, I wonder if we don't need to maintain it outside the std anymore? Or is there still any gap that we can fill in the std.

[Alexhuszagh]

@Alexhuszagh since rust-lang/rust#86761 brings most of fast-float code into Rust's std, I wonder if we don't need to maintain it outside the std anymore? Or is there still any gap that we can fill in the std.

For most cases: the Rust standard library does everything you need.

However, there are a few cases where you might want to use this library or another external float-parsing library (a lot of databases, for example, still use external libraries):

1. Performance above all else. The rust standard libraries makes a few conscious choices which impact performance by 5-10%. It's unlikely to affect real workloads except in highly specialized scenarios. However, tools like simdjson, which need performance, have migrated to the Rust standard library.
2. You need partial parsers: the Rust standard library only accepts a full input. You cannot provide 123.45b and then get (123.45, 6) (for the parsed number and the parsed characters) back. Doing validation then parsing is WAY slower than partial parsing.
3. You want faster algorithms for slow-case scenarios. My own implementation, lexical uses an algorithm that is much faster for edge-case floating point numbers. These are unlikely to occur in real-world scenarios, but it is a LOT faster in those edge cases.

That's why I both maintain the fast-float2 fork with these security fixes and lexical which has some faster algorithms in edge cases.

[tisonkun]

Thanks!

[tisonkun]

FYI You may also be interested in this issue rust-lang/libs-team#683