You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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).
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.
If you pass
XdgToplevel::set_title
a String with embedded 0 bytes (which is valid for aString
), you will get a panic with a backtrace that kinda looks like this: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:
wayland-rs/wayland-scanner/src/common.rs
Line 541 in df56d7d
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.The text was updated successfully, but these errors were encountered: