-
-
Notifications
You must be signed in to change notification settings - Fork 143
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
Writing to uninitialized buffer #90
Comments
This seems reasonable to me. I can't imagine any circumstances under which the |
I can't. Would it be breaking change to make the trait |
Ping? |
I don't think it would be a breaking change. Why does the standard |
There's a PR addressing this. |
I see. So it seems like the preferred solution is to make the trait |
Exactly. I'd submit a PR, but I'm currently low on time. I expect to have more time after ~2 weeks. |
Sorry, I forgot about this completely. I'll look at it today (not sooner than 9 hours from now). |
I think that if you're already dealing with unsafe code and uninitialized buffers, then it probably doesn't make sense to use byteorder's safe APIs, since they impose a cost. |
This is weird, I completely forgot about this. I do remember trying to add No change is actually required because performant writing can be done safely already: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=26babbb49afda7644f61f4e7ffe1ad2c TL;DR is that writing to a safe, 0-init array first and then copying it into uninit slice gets optimized just fine. Maybe a more appropriate label would be |
write_*
methods ofByteOrder
trait accept a buffer and don't guarantee that they wouldn't read from it. This has a drawback that strictly speaking, the provided buffer shouldn't be uninitialized.I suggest to provide some way of guaranteeing that the buffer won't be read from, so it's fine to pass uninitialized buffer.
The text was updated successfully, but these errors were encountered: