Implement Deref<Target=ByteStr> for CStr

[tamird]

This produces a deref chain of CStr -> BStr -> [u8] which is
present in the Rust-for-Linux analogues of these types.

Link: #134915
Link: Rust-for-Linux/linux#1075
Link: https://lore.kernel.org/all/20250221142816.0c015e9f@eugeo/
Link: Rust-for-Linux/linux#1146

r? @joshtriplett
cc @nbdd0121

I'm not entirely sure what it means for a stable type to deref to an unstable one - hopefully the compiler does the right thing and gates this impl on all the items being available.

[joshtriplett]

This is a really interesting idea. One potential point of concern: the deref to ByteStr uses to_bytes (rather than to_bytes_with_nul), which somewhat makes sense, but with the further deref to &[u8], is there any chance that someone will end up with a &[u8] that lacks the NUL when they expected a &[u8] that has the NUL?

This is probably fine, and I would hope that any FFI cases that require the NUL use CStr (or to_bytes_with_nul). However, I wanted to call it out as a potential hazard. If we do this, I think this deserves a mention in the documentation at least.

[tamird]

@joshtriplett sounds reasonable, except I'm not sure where to document this. I can't document it on the trait impl. Would it go in the CStr documentation? The documentation would in effect be insta-stable, which would be odd. What did you have in mind?

[joshtriplett]

I think it would go on CStr. Even before BStr is stable, the resulting transitive Deref to a slice will work, and that merits the documentation.

[tamird]

@joshtriplett done.

[joshtriplett]

Looks reasonable. Since trait impls are insta-stable, starting an FCP on this:

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

Concerns:

• &cstr as thin ptr (Implement Deref<Target=ByteStr> for CStr #138498 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

@rfcbot concern &cstr as thin ptr

Afaik, there is still a plan to make &CStr a thin pointer in the future. If we do that, then a deref to [u8] would mean counting the length (strlen) every time.