-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE #11403
Conversation
…rn value should be when the number of bytes transfered is larger than Long.MAX_VALUE
👋 Welcome back bpb! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
InputStream.transferTo is specified to transfer "all bytes from this input stream" so changing it to do a "short write" is major change and also creates a big inconsistency with java.io methods such as OutputStream.write that write all bytes.
I think other options will need to be explored. We have this same issue in other APIs where they specify that they return Long.MAX_VALUE when the size is larger.
It is likely that some of the overrides will need attention too.
Modified in 254d699 to transfer all bytes but clamp the return value to |
/csr |
@AlanBateman has indicated that a compatibility and specification (CSR) request is needed for this pull request. @bplb please create a CSR request for issue JDK-8297632 with the correct fix version. This pull request cannot be integrated until the CSR request is approved. |
I assume Reader.transferTo will need similar treatment. |
Looks like it. I will re-scan for other places as well. |
I assume this will require adjustments to SequenceInputStream.transferTo proposed in pull/11248. |
I will scan for all overrides. |
Correction: yes, that one has the same problem. |
Can you check ZipInputStream.transferTo? It has a partial copy of a lot of the InputStream javadoc because it has to insert "current ZIP entry" into the text. It's not possible to have a ZIP file larger than Long.MAX_VALUE so there may be nothing to do there but we should check the javadoc. |
That implementation just calls the overridden method, but the single sentence added to the |
I believe that makes sense |
Latest version (558cbc8) looks okay but this change will likely have a tail so I think we should wait until after the fork for JDK 20 to integrate this. To that end, I've changed the fixVersion to 21 and the same on the CSR, I hope that is okay. |
It can wait a week.
No problem. |
@bplb This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
@bplb This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
/open |
@bplb This pull request is now open |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version looks okay.
@bplb This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 894 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 5b2d430.
Your commit was automatically rebased without conflicts. |
long transferred = 0; | ||
while (in != null) { | ||
c += in.transferTo(out); | ||
if (transferred < Long.MAX_VALUE) { | ||
try { | ||
transferred = Math.addExact(transferred, in.transferTo(out)); | ||
} catch (ArithmeticException ignore) { | ||
return Long.MAX_VALUE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bplb , this looks like a bug to me: once transferred
reaches Long.MAX_VALUE
the transfer loop will terminate and the transfer will stop even in the case there are more streams available in the sequence.
I think the proper code should be transferred = Long.MAX_VALUE
instead of return Long.MAX_VALUE
(and there should be no if (transferred < Long.MAX_VALUE)
check)
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think?
I think that you are looking at an obsolete repository:
transferred = Long.MAX_VALUE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean SequenceInputStream, not the base class:
return Long.MAX_VALUE; |
Could you please double-check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO @vlsi is right. It is incorrect that we stop the transfer in the overflow case. We should fix it as he suggested. I can do that if you like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, the base class. The suggested change was made for InputStream
in 254d699. It looks like it should be in SequenceInputStream
as well. I created JDK-8322141 to track this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have any tests to check the behavior of the transferTo overrides when they transfer more than nine quintillion bytes so dependent on catching issues like this during code review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution proposed by @vlsi and outlined by @bplb in JDK-8322141 now can be reviewed in #17119. I suggest to continue the discussion there.
java.io.InputStream::transferTo
could conceivably return a negative value if the count of bytes transferred overflows along
. Modify the method to limit the number of bytes transferred toLong.MAX_VALUE
per invocation.Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403
$ git checkout pull/11403
Update a local copy of the PR:
$ git checkout pull/11403
$ git pull https://git.openjdk.org/jdk pull/11403/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 11403
View PR using the GUI difftool:
$ git pr show -t 11403
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11403.diff