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

String arguments should be CString #748

Open
Supreeeme opened this issue Jul 22, 2024 · 2 comments
Open

String arguments should be CString #748

Supreeeme opened this issue Jul 22, 2024 · 2 comments

Comments

@Supreeeme
Copy link
Contributor

If you pass XdgToplevel::set_title a String with embedded 0 bytes (which is valid for a String), you will get a panic with a backtrace that kinda looks like this:

thread 'main' panicked at ...
xdg.rs:138:5:
called `Result::unwrap()` on an `Err` value: NulError(<bytes>)
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <wayland_protocols::xdg::shell::generated::client::xdg_toplevel::XdgToplevel as wayland_client::Proxy>::write_request
   4: wayland_client::conn::Connection::send_request
   5: wayland_protocols::xdg::shell::generated::client::xdg_toplevel::XdgToplevel::set_title

This is a fairly obtuse error, but digging into the library, it appears this is because string arguments are converted to CStrings internally, with an unwrap:

vec![quote! { Argument::Str(#arg_name.map(|s| Box::new(std::ffi::CString::new(s).unwrap()))) }]

If wayland-scanner doesn't want to handle this error, then it makes no sense for String arguments to be String, when they should instead just be std::ffi::CString and leave it on callers to deal with constructing it.

@SUPERCILEX
Copy link
Contributor

I'd also like to see values provided to the library be Cow. I have a few places where I have some 'static strings that I'm forced to pointlessly allocate. It'd also be nice if the inputs were passed as &str and let us convert them to owned types (though I'm not sure how the recv buffering works internally so this may not be possible).

@ids1024
Copy link
Member

ids1024 commented Dec 24, 2024

If I recall correctly, now that Rust supports generic associated types, it should be possible now to update it to use borrowed types in the API, instead of String and Vec<u8>. Though that's a breaking change, and isn't a huge priority since these aren't too common in Wayland protocols (and large amounts of data are typically passed through shared memory fds).

Having to construct a CStr is annoying here. Though yeah, panicking internally when a string contains a null isn't great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants