On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer <oschmidt...@openjdk.org>
wrote:
> Windows programs may reuse a clipboard buffer that is larger than the new
> content. In this case de NUL terminator is not at the end of the buffer, but
> within it.
> The current implementation copys the whole buffer into a text field,
> including the NUL terminator and the remaining chars.
>
> The JIRA ticket contains a JNA based sample program, which prefills the
> buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.
I left a couple comments. As for an automated test, maybe there is something we
could do with FFM, but it might be a bit of a project to figure out how to
incorporate it into our test framework.
modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
line 255:
> 253: try {
> 254: // JDK-8118474 - internal Windows data null
> terminated
> 255: // JDK-8281384 - buffer might be larger than data
> and null terminator not at the end
Minor: We generally don't include the bug ID of the bug we are fixing in a
comment (and I see no need here).
modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
line 258:
> 256: int nullTerm = data.length - 2;
> 257: for (int i = 0; i < data.length; i += 2) {
> 258: if (data[i] == 0) {
Since this is UTF-16, don't you need to check that both the even and odd bytes
are 0?
if (data[i] == 0 && data[i+1] == 0) {
If you do this, you will want to validate that the length is even (if it isn't
already ensured by `popBytes`).
-------------
PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2641322865
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969912664
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969913328
