rust-lang
[feature request] Support Cstr literals
CStr literals (c"Hello, world!") and raw literals (cr"Hello, World!") are supported as of https://github.com/rust-lang/rust/pull/117472 and will be stabilized in ~1month. Would it be possible to add an option to emit this type of literal instead of &'static [u8] for string literals? If it sounds like a good idea, I can try and take a pass at it, it'd be nice for several of my projects.
I think the stabilization is getting reverted, unfortunately: https://github.com/rust-lang/rust/pull/119528
A bit unfortunate -- although I think bindgen support will be benefitted by the revert so more features (like proc_macro C string literals in https://github.com/rust-lang/rust/issues/119750) can make it in.
Bindgen support for this I think will be blocked by quote support for CStrs, which is blocked on syn support for them, which is blocked on proc-macro2 support, which is blocked on the issue/PR to proc_macro above. I'm planning on adding support to all of the above, but it'll take some time.
Looks like it will be re-stabilized in 1.78 on 3/21/24.
How would this interact with the existing generate_cstr option that will "will become enabled by default in a future release"? Would this just change the generated code from using ::core::ffi::CStr::from_bytes_with_nul_unchecked to using the new literal syntax?
I agree with @emilio, adding this as a nightly only feature meanwhile makes sense. If this feature is merged before the compiler feature is stabilized we can stabilize this feature and update the generate_cstr option in a single PR.
C-string literals was stabilized in Rust 1.77: https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html#c-string-literals
CStr literals don't exactly map to string literals in C, because a string literal may contain an embedded null byte. E.g. "ab\0c" will have to continue to be represented as a byte array.
A feature which automatically represented all strings without an embedded null as CStr and the rest as [u8] could be useful. However it would potentially be problematic/fragile as it would be changing data types based on seemingly irrelevant changes to string contents.
