xf_cliprdr: detect null terminators more reliably. (#5353)

Clipboard formats containing plain text are specified to be terminated
by a \0 character in MS's documentation on standard clipboard formats:
https://docs.microsoft.com/en-us/windows/desktop/dataxchg/standard-clipboard-formats

xf_cliprdr_server_format_data_response receives pasted data from the
server to transfer to the client, in a sufficiently raw form that the
\0 terminator is still present, so it has to remove it. It does so by
checking only at the very end of the data. But I've observed that when
pasting out of at least one Windows program (namely Outlook 1903 on
Windows 10), the intended paste data arrives in this function followed
by \0 and then a spurious \n. In that situation the null-terminator
removal will fail to notice the \0, and will leave both bogus
characters on the end of the paste.

Fixed by using memchr to find the _first_ \0 in the paste data, which
should not lose any actually intentional data because it's in
accordance with the spec above.

diff --git a/client/X11/xf_cliprdr.c b/client/X11/xf_cliprdr.c
index e9f91e4..b6fc52e 100644 (file)
--- a/client/X11/xf_cliprdr.c
+++ b/client/X11/xf_cliprdr.c
@@ -1444,8 +1444,9 @@ static UINT xf_cliprdr_server_format_data_response(CliprdrClientContext*
 
                if (nullTerminated)
                {
-                       while (DstSize > 0 && pDstData[DstSize - 1] == '\0')
-                               DstSize--;
+                       BYTE* nullTerminator = memchr(pDstData, '\0', DstSize);
+                       if (nullTerminator)
+                               DstSize = nullTerminator - pDstData;
                }
        }