lifthrasiir / hexf Goto Github PK

I wonder I can expect maintanance or have to fork. There is no activity since May 2019.

Hex literals with a mantissa that would be larger than 64 bits before applying the exponent are incorrectly rejected. For example,

parse_hex64("0x10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000p-1474", false)

returns an error.

The Naga crate uses hexf_parse to handle hex float literals in WGSL. Our front end has already verified that the text conforms to WGSL's grammar for hex float literals, but since that grammar has subtle differences from this library's grammar, we have to use format! to reassemble the pieces into what parse_hexf64 expects.

It'd be nicer if this library could accept a struct like this:

struct HexFloatParts<'a> {
    negative: bool,
    integer: Option<&'a str>,
    fraction: Option<&'a str>,
    exponent: Option<&a str>,
}

The CC0-1.0 license is no longer considered to be a suitable license for code by some lawyers in the open-source licensing space (it is still considered a "good" license for content). For example, code licensed under the CC0-1.0 license is no longer allowed to be packaged for Fedora Linux since July 2022: https://lists.fedoraproject.org/archives/list/[email protected]/message/RRYM3CLYJYW64VSQIXY6IF3TCDZGS6LM/

For context - I am currently working on packaging ruff (a very fast Python linter) for Fedora Linux, and one of its dependencies is the hexf-parse crate. Currently, providing a package for ruff would be blocked because hexf-parse cannot be packaged and / or distributed by us.

Alternatives to CC0-1.0 that are still "good" licenses for code might be Unlicense, MIT-0, or 0BSD. Note that of these three, only the Unlicense appears to be considered a FOSS license by both the FSF and the OSI, whereas MIT-0 and 0BSD are only OSI-approved (c.f. https://spdx.org/licenses/).

That should be fairly simple to fix I think. This is a valid hex float:

0x1p-149

-- however it triggers "unable to parse" error.

According to this comment, we can use a union to construct the float value more directly.

It might be worth going through that route to avoid depending on the float parsing machinery.

hexf panics on the following code:

hexf_parse::parse_hexf64("0x.000000000000000000102");

The backtrace points to this line: https://github.com/lifthrasiir/hexf/blob/master/parse/src/lib.rs#L138

It looks like you try to catch the error the line before, I'm not sure why it still keeps going: https://github.com/lifthrasiir/hexf/blob/master/parse/src/lib.rs#L135

thread 'main' panicked at 'attempt to shift left with overflow', /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/hexf-parse-0.1.0/src/lib.rs:138:19
... panic code ...
  15: hexf_parse::parse
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/hexf-parse-0.1.0/src/lib.rs:138
  16: hexf_parse::parse_hexf64
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/hexf-parse-0.1.0/src/lib.rs:394
... my code ...

fn main() {
    assert_eq!(
        0.1171875,
        hexf_parse::parse_hexf64("0x0.1E", false).expect("failed to parse")
    );
}

output:

thread 'main' panicked at 'failed to parse: ParseHexfError { kind: Invalid }', src/main.rs:4:51

I have no idea how floats work, so apologies if this is a mistake.

I just checked if hexf 0.2.1 can compile with Rust 1.43 and it seems to work just fine. Was there any particular reason for the MSRV of 1.45? If possible I'd appreciate it if the MSRV could be lowered to 1.43 (at least for versions 0.2.x), as this would allow me to use hexf-parse for gfx-rs/naga#1184.

Looks like the version has been bumped in the repo but the latest version on crates.io is still 0.1?