dtolnay / itoa Goto Github PK

I need to pass the string that itoa returns to C, which means I need to add a null byte at the end. But there's no way to do that with the &str that format returns, short of copying the string's contents to an entirely new buffer.

If itoa exposed a method that accepted a pointer or reference to a user-created MaybeUninit buffer of the right size, I would be able to do this easily (just set the index one past the number of bytes that were written to 0).

This crate should not be necessary. It should be possible to optimize write!(&mut buf, "{}", value) to do what this crate does.

Would it be possible to create an example for when using nostd? It works great using itoa::write with std, but I get the following error using itoa::fmt in nostd:

the trait 'core::fmt::Write' is not implemented for '[u8]'

on this line:

let n = itoa::fmt(buffer[..], num).unwrap();

Thanks :)

Hi was just passing through and might have spotted something slightly amiss.

I agree that i64 and u64 has different max lengths (19, 20) but I don't believe this is the case for 128:

Shouldn't they both be 39?

(also if we're there we should probably make that other constant only available with the feature)

(If you agree I'll raise a PR to adjust.)

Most of the times, the buffer has prefix/postfix strings and you need to append/prepend a number to it. An API comparable to this would be ideal:

fn demo_itoa_fmt() -> fmt::Result {
    // Write to a string.
    let mut s = String::from("Result is: ");
    itoa::fmt_append(&mut s, 128u64)?;
    println!("{}", s); 

    Ok(())
}

There is no way to know how many bytes were written in the result, which is a problem when using write with a stack-allocated array. Returning io::Result<usize> would allow this:

let mut buf = [b'\0'; 20];
let len = itoa::write(&mut buf, value)?;
let result = &buf[0..len];

The readme is helpful but https://docs.rs/itoa needs a lot of work.

https://github.com/dtolnay/itoa/blob/master/src/lib.rs#L119

Currently if I need to write an integer to a fixed size buffer I need to lookup how large of a buffer I need for the integer size and create it manually, either with zero initialization or unsafe. Further this buffer will not be directly written to as the crate creates its own buffer.

If the crate exposed a buffer type like https://docs.rs/ryu/0.2.6/ryu/struct.Buffer.html this could be avoided and hidden behind a safe interface.

pub trait Integer {
    const MAX_SIZE: usize;
}
pub struct Buffer<I> where I: Integer { buf : [u8: I::MAX_SIZE] }

Since associated constants are a relatively new Rust feature this could need some build.rs trickery and/or an extension trait but I'd be willing to submit a PR if this seems reasonable.

I'm interested in hexadecimal output in the same vein as itoa::fmt, and to do that I've extracted the code from libcore.

The C function itoa takes an argument for the radix, so I thought it would make sense to add the code to this crate, if you're interested. The question is what should the API look like. libcore provides a few traits for Binary, Octal, and Hexa, I think it would make sense to expose similarly named traits with the same functions as in the itoa::Integer trait.

What do you think?

one of things that you must ship ASL 2.0 license text within sources, but it is also needed for distro packaging

The Integer trait should probably have some bounds making to more convenient to use in generic code. I suggest adding at least Sized, Clone and Copy. We could also add math ops traits, but if you need this you should probably be using the num crate. For the other traits implemented by integers, I don’t know. The std::fmt traits might make sense, but they are not no-std if we want support that later.

Rust’s 128-bit integer types are currently unstable and feature gated behind the i128_type and i128 gates. It would be great if this crate supported them on nightly until they eventually become stabilized.

Since we've had these types stable since 1.26, would it be worth changing the docs?

Is it possible to provide a function to write the output directly into a provided u8 slice?

Before 1.0.0, itoa used std::mem::uninitialized to use uninitialized u8s. This is now regarded as being undefined behaviour, and itoa correctly switched to MaybeUninit instead some time ago. But this switch came with a new major version, meaning crates that still depend on old itoa (like the current published version of csv) do not get that soundness fix.

See: rust-lang/rust#66151 for more info around mem::uninitialized.

Therefore, I would suggest backporting a soundness fix for 0.4.x. We can't use MaybeUninit, since that would increase the MSRV which is probably not desired. I would suggest to zero-initialize it instead. While this can come at a minor perf impact, it's for an old and outdated version, and most people will likely have upgrade their dependencies already. This would also be a really simple change.

What's your opinion on this? Is this something we should do right now? Maybe at a later point in the future?