Uh oh!
There was an error while loading. Please reload this page.
Use an uninitialized buffer in GenericRadix::fmt_int, like in Display::fmt for numeric types - #49103
Conversation
…::fmt for numeric types The code using a slice of that buffer is only ever going to use bytes that are subsequently initialized.
rust-highfive
commented
Mar 17, 2018
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cramertj (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
shepmaster
commented
Mar 23, 2018
As a drive-by comment, have you performed any profiling to see that this change has any benefit? |
shepmaster
commented
Mar 23, 2018
Ping from triage, @cramertj — will you have time to review this soon? |
cramertj
commented
Mar 25, 2018
@bors r+ rollup |
bors
commented
Mar 25, 2018
📌 Commit 38cbdcd has been approved by |
Use an uninitialized buffer in GenericRadix::fmt_int, like in Display::fmt for numeric types The code using a slice of that buffer is only ever going to use bytes that are subsequently initialized.
Use an uninitialized buffer in GenericRadix::fmt_int, like in Display::fmt for numeric types The code using a slice of that buffer is only ever going to use bytes that are subsequently initialized.
glandium
commented
Mar 26, 2018
FWIW, it didn't make a significant difference in my use cases, but I suspect it can for some embedded platforms. |
The code using a slice of that buffer is only ever going to use
bytes that are subsequently initialized.