Suggestion: CStr literals

[LunarLambda]

Why?

Currently, creating a CStr, even from a bytestring literal, is quite noisy.

// NOTE: Don't forget to add \0 at the end or this is unsound!
let cstr = unsafe { CStr::from_bytes_with_nul_unchecked(b"Hello, World\0") };

Furthermore, there's no way to ensure the well formed-ness of that literal at compile time¹, despite hardcoded C-strings being fairly common when creating bindings for C libraries.

How?

To address this, I would like to propose a new string literal type:

let cstr = c"Hello, World!";

It would function nearly identical to byte-string literals, with the following key differences:

1. Its type is &CStr, not &[u8]
2. It may not contain any nul bytes (\0, \x00 as well as a 'physical' nul byte are forbidden)
3. The compiler automatically adds a nul byte at the end of the string.

See also "Alternatives?" below.

Pros?

• Fills a niche in the language people are forced to build around²
• Allows creation of const CStr items (currently not possible on stable)

Cons?

• Have to commit to adding a new literal (sub)type to the language, which may require small tweaks to the parser

Alternatives?

1. Make associated functions on CStr const. This would still leave the burden of checking on the user.
2. Add a cstr! macro taking a byte-string literal and applying the needed checks and transformations.

¹ It is possible using proc-macros, though this poses different issues regarding ergonomics and stability.
² GitHub code search for CStr::from_bytes_with_nul_unchecked

[tesuji]

Alternative: Make CStr associated methods const. That is a lib changes only rather than a language change.

[jonas-schievink]

Another alternative: Provide a cstr! macro that turns a regular string literal into a &'static CStr (and checks that it doesn't contain null bytes)

[LunarLambda]

Alternative: Make CStr associated methods const. That is a lib changes only rather than a language change.

This does not resolve the ergonomics / potential unsoundedness issue

Another alternative: Provide a cstr! macro that turns a regular string literal into a &'static CStr (and checks that it doesn't contain null bytes)

A macro would work (and is in fact probably better as CStr is specific to std and not a built-in type), but would have to take a byte string, as C-strings need not conform to any encoding, including str's UTF-8.

[jonas-schievink]

It could take either, it just has to check that there's no 0 bytes contained within

[Lokathor]

Yeah this can just be a proc macro in a crate that takes a string literal or byte string literal and then produces a &[u8].

[LunarLambda]

I suppose so. I still think it would make sense to include it into `std`/rustc. I'm not familiar with writing proc-macros, unfortunately

…

On Wed, 12 Aug 2020, 01:22 Lokathor, ***@***.***> wrote: Yeah this can just be a proc macro in a crate that takes a string literal or byte string literal and then produces a &[u8]. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#75401 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJI55IXFNDIV6ZNQYG6FWSTSAHHFBANCNFSM4P27NFHQ> .

[Lokathor]

Probably something similar to this https://github.com/Lokathor/utf16_lit/blob/main/src/lib.rs#L62, but instead of recoding the bytes from utf8 into utf16, you'd just spit them out directly as u8 values.

[Nemo157]

Combining the suggestions, cstr! could soon just expand to:

const { CStr::from_bytes_with_nul($input).unwrap() }

no proc-macros necessary.

[tesuji]

Is inline const implemented?

[Nemo157]

No, but it is RFC-accepted and doesn't seem terribly hard to implement (he says as a non compiler developer).

[Lokathor]

IIRC, concat! cannot currently work with bytestring values, so that is one limit to the macro_rules version.

Still, regardless of the macro details, I think we can all agree that this ability, while nice, doesn't need to exist directly within the compiler or standard library. It can be done as a standard user crate.

So people should make the helper macro they want as a crates.io crate, and then worry about it maybe being moved into the standard library at a later date.

[Nemo157]

The const features required to make that work are not near stabilization, so only std could feasibly implement it that way in the near future (it would be possible to do without inline const, but even making from_bytes_with_nul a stable const fn seems quite far away given it needing reference transmutes, and I'm unsure of the const-panic status).