upsuper / cstr Goto Github PK

The only thing needing is the function to parse a string literal, do we really need to bring in all of syn for that? Would you consider merging a PR that duplicates syn's own function to parse a string?

We can drop the hack once rust-lang/rust#68717 gets merged and reaches stable.

Hi,

I'd like to include a file as a CStr. The include_str! macro lets me include one as a str, but I need it to be null-terminated because it's used to call a specific FFI function that expects a null-terminated string. The cstr! macro fails to compile if include_str! is used as its input, and using a separate static for include string doesn't work because the name is converted to a CStr rather than its contents. Would it be possible for this crate to support this use case?

I stumbled across this PR in the Rust repository rust-lang/rust#82057 and discovered your crate.

I recently added a cstr dep in Artichoke: artichoke/artichoke#1085.

I wanted to say thank you. This crate fills a niche for me.

core::ffi::CStr and alloc::ffi::CString have been stabilized for Rust 1.64, which is due to become stable in 9 weeks from now.

Would you consider making this crate no_std? AIU all it'd need to do is to

• lib.rs needs a #![cfg_attr(not(proc_macro), no_std)]
• guard content in lib.rs with #[cfg(proc_macro)]. Given that it's almost every line that needs guarding, this might best be done by moving code from src/lib.rs into a module.
• change the quoted ::std::ffi::CStr to `::core::ffi::CStr``.

I can offer a PR, but it's probably all more a matter of chosen style and how to handle the MSRV increase than of the actual change.

I got error "package cstr v0.2.11 cannot be built because it requires rustc 1.64 or newer, while the currently active rustc version is 1.60.0-nightly" after download today's nightly build
Even though my version is

info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: checking for self-updates

nightly-x86_64-pc-windows-msvc unchanged - rustc 1.66.0-nightly (4a1467723 2022-09-23)

Using the cstr macro results in the clippy warning #[warn(clippy::transmute_ptr_to_ref)]

warning: transmute from a pointer type (`*const std::ffi::CStr`) to a reference type (`&std::ffi::CStr`)
 --> src/main.rs:3:20
  |
3 | const FOO: &CStr = ::cstr::cstr!("foo");
  |                    ^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(clippy::transmute_ptr_to_ref)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#transmute_ptr_to_ref
  = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Is it possible to avoid this warning without disabling the check?

If not, is there a way to disable this lint for invocations of this macro without disabling this lint for my whole project?

Upstream Rust std is stabilizing a const version of CStr::new_unchecked:

• rust-lang/rust#91855

Do you have interest in bumping this crate's MSRV to use this API from std once it is released? It would enable removing the mem::transmute code which looks pretty intense.