pasted text on host doesn't include the last character, from wayland guest

[foofoofeefeebambam]

tl;dr: the attached patch ensures the null terminator of utf16 strings is part of the returned size, else pasted clipboard on host (even though copied correctly from a wayland guest) doesn't include the last character in the text.

Long read(no need): I've Arch Linux kde plasma wayland running as guest OS, and Windows 11 as host OS. VBoxClient --wayland running on guest OS (because VBoxClient --clipboard can't paste on host (wayland lacks support? as per ​https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26 ) )

I'd note that archlinux does apply some patches on virtualbox&co which I haven't really checked: ​https://gitlab.archlinux.org/archlinux/packaging/packages/virtualbox/-/tree/7.1.6-2?ref_type=tags

But I don't believe they affect this bug.

I've a patch for 2 places (didn't really look for more) which don't properly return the size of the buffer they made (it's off by one, in the less direction). I've tested it to work: the pasted text includes the last character, ie. I copy "sometext" in guest OS, then paste it on host OS as "sometext" instead of "sometex", that is, when pasting to host actually does paste anything at all(another bug report about this not pasting on host incoming later, EDIT: ok here: https://www.alldomusa.eu.org//ticket/22340 ).

I've tested this with gentoo host too, but it was an older version of virtualbox, it works the same (in bugged and patched versions, regarding this issue) but it hangs more and is unreliable possibly due to being too old and not same version as the guest OS's virtualbox things.

To my limited understanding, what's happening here with this patch is that text copied on guest OS from Konsole terminal(as latin1) or from mousepad(as utf8), gets transformed (from native) into vbox format which is apparently utf16 plus zero terminator (which is 1 utf16 zero char, which is two zero bytes) (note that the zero terminator is added to the utf16 string, it didn't exist in the native(latin1 or utf8) string), but without the patch, the zero terminator wasn't counted even though it was put in there, so somehow something(ahem, in func. VbglR3ClipboardWriteDataEx, these 2 lines: Msg.Parms.pData.SetPtr(pvData, cbData/*+1*/); and rc = VbglR3HGCMCall(&Msg.Hdr, sizeof(Msg));) took the clipboard as being 1 character less thus pasting it without the last character(so pasting "something" would be pasted as "somethin", without the "g"). There may or may not be other places where this off-by-one error is present, I haven't really looked, please check?. Also, I look with zero understanding of what's going on, had to guess/debug what's going on, so maybe, MAYBE, I'm wrong about all this, even though it seems obvious now in retrospect what's going on, in this issue. Actual devs should double check me :) I'm not a dev, btw, but was happy to waste 1 day on this.

Note that for this copy/pasting to work at all, there's the requirement that on kde plasma wayland the systray Clipboard must be showing (definitely not Disabled) - this can be changed in Configure System Tray menu that appears if you RMB on the free space or up arrow of systray, then under Entries, Clipboard. (I haven't tried if 'Always hidden'/'Show when relevant' works, but 'Always showing' does work and Disabled does not.)

[foofoofeefeebambam]

patch that includes the utf16 null terminator in size computation when returning