CString does not preserve capacity #74794
Labels
C-bug
Category: This is a bug.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Simplest repro:
I expected
CString
to behave likeString
, preserving capacity from theVec
it was created. Instead, theCString
implementation shrinks-to-fit and stores a boxed slice, which is then converted back intoVec
ininto_bytes
/into_bytes_with_nul
, giving back as much capacity as there were elements, i.e. 1 which is the nul terminator.I vaguely understand the reasoning for this — when
&CStr
becomes a narrow pointer,Box<CStr>
would be a narrow pointer too, meaning thatCString
also will; in such a case, ifCString
was aVec
instead, it would be three pointers in size (pointer, size, capacity). This means, however, that there's no reason to useCString
instead ofBox<CStr>
, making it essentially useless.In other words, the only reason for
String
/OsString
/CString
to exist in parallel withBox<str>
/Box<OsStr>
/Box<CStr>
is to provide the same safety guarantees for the contents while also providingVec
-like functionality (growing/shrinking and spare capacity). In reality,CString
does not provide those at all, much likeOsString
(though it'd be considerably more complex to implementpush
/pop
forOsString
on Windows even if it's aVec
, since that'd mean that encoding and decoding the underlying WTF-8 would be required).As an initial effort,
OsString
andCString
can be transformed intoVec
s transparently to their public APIs. Then, theVec
API can be integrated via the usual RFC process.Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: