flt2dec: properly handle uninitialized memory #76241
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The float-to-str code currently uses uninitialized memory incorrectly (see #76092). This PR fixes that.
Specifically, that code used
&mut [T]
as "out references", but it would be incorrect for the caller to actually pass uninitialized memory. So the PR changes this to&mut [MaybeUninit<T>]
, and then functions return a&[T]
to the part of the buffer that they initialized (some functions already did that, indirectly via&Formatted
, others were adjusted to return that buffer instead of just the initialized length).What I particularly like about this is that it moves
unsafe
to the right place: previously, the outermost caller had to useunsafe
to assert that things are initialized; now it is the functions that do the actual initializing which have the correspondingunsafe
block when they callMaybeUninit::slice_get_ref
(renamed in #76217 toslice_assume_init_ref
).Reviewers please be aware that I have no idea how any of this code actually works. My changes were purely mechanical and type-driven. The test suite passes so I guess I didn't screw up badly...
Cc @sfackler this is somewhat related to your RFC, and possibly some of this code could benefit from (a generalized version of) the API you describe there. But for now I think what I did is "good enough".
Fixes #76092.