Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add cstr! macro for creating &'static CStrs. #103

Closed
reitermarkus opened this issue Sep 13, 2022 · 5 comments
Closed

Add cstr! macro for creating &'static CStrs. #103

reitermarkus opened this issue Sep 13, 2022 · 5 comments
Labels
api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api

Comments

@reitermarkus
Copy link

Proposal

Problem statement

Now that core::ffi::CStr is stabilized, there should be an ergonomic way to create &CStr constants.

Motivation, use-cases

On stable there is currently no good way to create a &'static CStr, the simplest solution needs unsafe, i.e.

const MY_C_STRING: &CStr = unsafe { CStr::from_bytes_with_nul_unchecked(b"Hello, world!\0") };

On nightly, it is possible since rust-lang/rust#100291 without unsafe, but these are even more verbose or don't provide meaningful error messages:

#![feature(const_cstr_methods)]

const MY_C_STRING: &CStr = if let Ok(s) = CStr::from_bytes_with_nul(b"Hello, world!\0") {
    s
} else {
    panic!("contains interior nul bytes")
};
#![feature(const_cstr_methods)]
#![feature(const_option)]

const MY_C_STRING: &CStr = CStr::from_bytes_with_nul(b"Hello, world!\0").ok().unwrap();

Solution sketches

With a cstr!, the example above becomes both easier to write and easier to read, i.e.

const MY_C_STRING: &CStr = cstr!("Hello, world!");

Links and related work

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

@reitermarkus reitermarkus added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Sep 13, 2022
@thomcc
Copy link
Member

thomcc commented Sep 14, 2022

I'm broadly in favor of this -- it's worth considering what syntax we'd want for this under rust-lang/rfcs#3267 (although, I guess I'm unsure the future that RFC has).

@m-ou-se
Copy link
Member

m-ou-se commented Oct 18, 2022

I've nominated rust-lang/rust#101607 for lang team discussion, to discuss the c"abc" alternative.

@m-ou-se
Copy link
Member

m-ou-se commented Nov 15, 2022

I've opened rust-lang/rfcs#3348 as an alternative.

@SUPERCILEX
Copy link

I actually just ran into this! I'll echo Thom about broadly wanting this and say that I'd prefer Mara's solution over a macro, but would settle for either.

@m-ou-se
Copy link
Member

m-ou-se commented Feb 13, 2023

Closing this, because rust-lang/rfcs#3348 has been accepted.

@m-ou-se m-ou-se closed this as completed Feb 13, 2023
@dtolnay dtolnay closed this as not planned Won't fix, can't repro, duplicate, stale Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api
Projects
None yet
Development

No branches or pull requests

5 participants