Document the requirement on recomputed length for CString::from_raw · Issue #48525 · rust-lang/rust (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Appearance settings

Description

A recent Doc PR for CStr reminded me of this:

https://users.rust-lang.org/t/cstring-from-raw-danger/15340

• CString::from_raw should make it clear that the length isn't just "recomputed," but that the recomputed length must match the original length. Yes, this can be inferred from the clearly-stated invariants of the type, but I feel this is important enough to deserve a sentence all of its own in the Unsafety section of the from_raw method, because it singlehandedly cripples a very wide range of would-be use cases for CString.
• CString::into_raw should steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL. (But what should we steer them towards? Vec<c_char>, probably? Hard to create one from string data though, compared to Vec<u8>...)