running 16 tests
test base10_i16_array_just_right ... ok
test base10_i32_array_just_right ... ok
test base10_i16_array_too_small ... FAILED
test base10_i32_array_too_small ... FAILED
test base10_i8_array_just_right ... ok
test base10_i64_array_just_right ... ok
test base10_i64_array_too_small ... FAILED
test base10_i8_array_too_small ... FAILED
test base10_u16_array_just_right ... ok
test base10_u16_array_too_small ... FAILED
test base10_u32_array_just_right ... ok
test base10_u32_array_too_small ... FAILED
test base10_u64_array_just_right ... ok
test base10_u64_array_too_small ... FAILED
test base10_u8_array_just_right ... ok
test base10_u8_array_too_small ... FAILED

failures:

failures:
    base10_i16_array_too_small
    base10_i32_array_too_small
    base10_i64_array_too_small
    base10_i8_array_too_small
    base10_u16_array_too_small
    base10_u32_array_too_small
    base10_u64_array_too_small
    base10_u8_array_too_small

I'm packaging numtoa for Fedora and those tests are failing, not sure what information to attach honetsly.

I see benchmark numbers in the readme but the code isn't in the repo. Could you share the code so I can reproduce those on my machine? Really what I am wondering is how the comparison changes if I do have an io::Write that I need to write to, as is the case in serde_json. With numtoa I would have to copy the bytes from my buffer over to the io::Write which I imagine would cut into the 8% advantage.

If we double anything greater than +63 for i8 we get an overflow I'm afraid so there's a slight chink in the armour between 64-99 for i8.

https://github.com/mmstick/numtoa/blob/429fa9cd603f02c08cc712787ba13b330a320bfc/src/lib.rs#L310

(Sorry my usage of the crate tests it pretty well as I'm using it to drive my own test harness!)

+ /usr/bin/cargo test -j6 --release --no-fail-fast
   Compiling numtoa v0.1.0 (file:///builddir/build/BUILD/numtoa-0.1.0)
     Running `/usr/bin/rustc --crate-name numtoa src/lib.rs --emit=dep-info,link -C opt-level=3 --test -C metadata=a8991c65fdb394d2 -C extra-filename=-a8991c65fdb394d2 --out-dir /builddir/build/BUILD/numtoa-0.1.0/target/release/deps -L dependency=/builddir/build/BUILD/numtoa-0.1.0/target/release/deps -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now`
error[E0599]: no method named `numtoa_str` found for type `{integer}` in the current scope
   --> src/lib.rs:401:33
    |
401 |     assert_eq!("256123", 256123.numtoa_str(10, &mut buffer));
    |                                 ^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0599`.
error: Could not compile `numtoa`.

Built on Fedora Rawhide with Rust 1.29.1

Also it seems the source code on this repo is outdated and the Gitlab repo is not accessible.

Here: https://github.com/mmstick/numtoa/blob/master/src/lib.rs#L241

Wouldn't it be better to write an universal implementation and just call it from generic impls?

Hello,

I am trying to write a function that calls numtoa shown below:

fn render_num<T: NumToA>(num: T, buffer: &'a mut [u8; 20]) -> Font6x8<'a> {
        let n = num.numtoa(10, buffer);

        let text = from_utf8(&buffer[..n]).unwrap();

        Self { pos: (0, 0), text }
}

but I get the error wrong number of type arguments: expected 1, found 0, highlighting T: NumToA. How do I correctly implement this function?

Thanks :)

This code assumes base 10 in case of smallest signed numbers like -128 and -32768, leading to incorrect results if base is not 10. Sample test:

let mut buffer = [0u8; 4];
let i = (-128i8).numtoa(8, &mut buffer);
assert_eq!(&buffer[i..], b"-200"); // Fails as the buffer is equal to b"-148"

For instance the i16 number -32768 fits in a 6 byte buffer but trying to format that number in a 6 byte buffer using numtoa results in a panic:

extern crate numtoa;

use std::str;

use numtoa::NumToA;

fn main() {
    let mut buffer: [u8; 6] = *b"-32768";

    let start = (-32768_i16).numtoa(10, &mut buffer);

    println!("{}", str::from_utf8(&buffer[start..]).unwrap());
}

$ cargo run
thread 'main' panicked at 'attempt to subtract with overflow', /home/japaric/.cargo/registry/src/github.com-1ecc6299db9ec823/numtoa-0.0.7/src/lib.rs:231
note: Run with `RUST_BACKTRACE=1` for a backtrace.

But if you use a 7 byte buffer the operation succeeds. You don't see this behavior when formating positive integers: for example, formatting 65535_u16 works fine with a 5 byte buffer.

extern crate numtoa;
use numtoa::NumToA;

fn main() {
    let mut buf = vec![0; 20];
    let start = (256i16).numtoa(10, &mut buf);
    let s = ::std::str::from_utf8(&buf[start..]).unwrap();
    assert_eq!("256", s); // :(
}

Fixes: #17 For i64 the way the numbers fall it actually requires one less byte than u64. This is certainly true for base 10. Does this hold for other bases?

If I know for sure that I have numbers in the range 0 .. 100_000_000, I want to be able to use an 8-byte buffer rather than needing 20 bytes in debug mode. Maybe an unsafe way to skip the check? This is why https://github.com/mmstick/numtoa/issues/5#issuecomment-274347968 panics in debug mode even though the code is correct.

https://github.com/mmstick/numtoa/issues/4#issuecomment-274293855

Based on the benchmark code in #4 but writing to Vec<u8>, itoa is about 10% faster.

let mut null = Vec::new();

for number in 0..100_000_000u64 {
    null.clear();
    /* write */
}

numtoa: 995 ms
itoa: 866 ms
std: 2803 ms

This is an important use case because it is a good model of what serde_json::to_string is doing, for example.