BREAKING: use Cow<'static, CStr> for string argument

[CrazyboyQCD]

Closes #748.
Leave construction of string argument to caller and make ffi process less panic-proned, and is benefit for users whose rust version is above 1.77 to use C-string literals

[ids1024]

If arguments take Cow, then all callers will have to explicitly convert to a Cow. A generic requiring Into<Cow<'_, CStr>> could be better, though that still isn't implemented for types like &str.

Perhaps a custom trait like Rustix uses would be best here: https://docs.rs/rustix/1.0.3/rustix/path/trait.Arg.html.

[ids1024]

In principle using CStr in the API is quite correct since Wayland requires null-terminated strings, but it may be annoying to deal with.

[i509VCB]

There is also the issue that strings in Wayland are rather undefined in their use. Nothing stops a client from sending you malformed UTF-8 or UTF-16.

The two exceptions are xdg-toplevel titles (explicitly defined as UTF-8) and the identifier the compositor created for ext-foreign-toplevel-handle (printable ASCII)

[ids1024]

Right. As defined in https://wayland.freedesktop.org/docs/html/ch04.html, I guess technically the only difference between strings and arrays is null-termination? And this seems to imply there shouldn't be other nul bytes, though I don't see that explicitly mentioned.

So CStr/CString is correct here, though a pain to work with. Life would be easier if wayland was more specific and libwayland did utf-8 validation for strings.

[CrazyboyQCD]

@ids1024
After overview, I found a auto-convert trait argument will increase code complexity and make product bloaty, thought callers need to deal with this, it is more flexible for callers if they want to be more performant.

[ids1024]

Yeah, there's not a clear best way to do this.

Converting a &str to a CStr manually is a bit annoying, but strings aren't really that common in wayland protocols (and higher level APIs like smithay and smithay-client-toolkit can decide what is suitable as a higher level API for a specific protocol). And having to deal with CStrings that may or may not be valid UTF-8 in return values is necessary regardless.

[orowith2os]

I will also note that the Wayland protocol defines a string argument as:

Starts with an unsigned 32-bit length (including null terminator), followed by the string contents, including terminating null byte, then padding to a 32-bit boundary. A null value is represented with a length of 0.

We need the null terminator, but it's not necessarily used for counting the string's length. That's something C-based Wayland clients can do.

And here's a note in CStr's documentation on count_bytes:

Note: This method is currently implemented as a constant-time cast, but it is planned to alter its definition in the future to perform the length calculation whenever this method is called.

It would be better to take a &mut String (or a Cow<_, String>) and check for a NUL byte, add it if one doesn't exist, and then pass it as an argument. It would also need to make sure that there's no NUL byte in the middle of the string.

[orowith2os]

Recent versions of the core Wayland protocol will also require that all strings used are valid UTF-8: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/387

[orowith2os]

Correction: Cow<str> would probably be better? Then append NUL to that. Would also need to perform validation so that it doesn't pass a string with two NUL bytes.