Skip to content

[feature request] Support Cstr literals #2710

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
novafacing opened this issue Jan 5, 2024 · 9 comments
Closed

[feature request] Support Cstr literals #2710

novafacing opened this issue Jan 5, 2024 · 9 comments

Comments

@novafacing
Copy link

CStr literals (c"Hello, world!") and raw literals (cr"Hello, World!") are supported as of rust-lang/rust#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.

@novafacing novafacing changed the title feature request: Support Cstr literals [feature request] Support Cstr literals Jan 5, 2024
@Property404
Copy link

I think the stabilization is getting reverted, unfortunately:
rust-lang/rust#119528

@novafacing
Copy link
Author

A bit unfortunate -- although I think bindgen support will be benefitted by the revert so more features (like proc_macro C string literals in rust-lang/rust#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.

@emilio
Copy link
Contributor

emilio commented Jan 12, 2024

Seems fine to add an experimental feature. See bindgen/features.rs.

@wmmc88
Copy link

wmmc88 commented Mar 11, 2024

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?

@pvdrz
Copy link
Contributor

pvdrz commented Mar 12, 2024

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.

@teohhanhui
Copy link

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

@GKFX
Copy link
Contributor

GKFX commented May 22, 2024

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.

@nyurik
Copy link
Contributor

nyurik commented Nov 28, 2024

@GKFX the c"ab\0c" (a C-string literal as stabilized in 1.77) is a compilation error.

@pvdrz
Copy link
Contributor

pvdrz commented Dec 2, 2024

fixed via #2996

@pvdrz pvdrz closed this as completed Dec 2, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

8 participants