xf_cliprdr: detect null terminators more reliably. (#5353)
authorsgtatham <anakin@pobox.com>
Thu, 25 Apr 2019 08:54:10 +0000 (09:54 +0100)
committerakallabeth <akallabeth@users.noreply.github.com>
Thu, 25 Apr 2019 08:54:10 +0000 (10:54 +0200)
commit236c7918cb7bfd3781aeeba8df40f3ca4467065c
tree0599a54d1cea65442e97587a91292c8951769c0f
parentf9dab4f012e39c4c3fdee342e14e02cc08a9e915
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.
client/X11/xf_cliprdr.c