Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose a safe way to efficiently write to an uninitialized, fixed buffer #19

Closed
Marwes opened this issue Sep 7, 2018 · 3 comments
Closed

Comments

@Marwes
Copy link
Contributor

Marwes commented Sep 7, 2018

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.

@dtolnay
Copy link
Owner

dtolnay commented Sep 7, 2018

I like the API in ryu a lot. I would be on board with picking that up here. Please send a PR!

In your use case is it important to use the smallest possible buffer for each integer type or can we just use [u8; 40] everywhere which fits any primitive integer?

@Marwes
Copy link
Contributor Author

Marwes commented Sep 7, 2018

I wouldn't say it is important (bench first and all) but my first thought was just to expose the max size. Other than that it would make it possible to preserve the current internal api which has the explicit per integer sizes so I figured why not do that tiny bit of optimization.

@dtolnay
Copy link
Owner

dtolnay commented Sep 7, 2018

I would go with [u8; 40] for now even if it means some restructuring internally. If you decide to implement both ways and find measurably better performance from using a smaller buffer for smaller types, then we can go with the faster way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants