Hi Brian, Hmmm... Just thinking aloud:
Should InputStream provide a safe but non-optimized version of skipNBytes() that does not rely on skip(), and should subclasses that override skip() for performance also be changed to override skipNBytes too if performance improvement can be gained? best regards, -- daniel On 25/10/2018 01:14, Brian Burkhalter wrote:
Hi Sergey, That is rather ugly. Thanks for pointing it out. The previous version which merely repeatedly read and discarded a buffer of bytes did not have this problem, but it also did not take advantage of any performance improvement to be obtained by subclass overriding of skip(). It does introduce some randomness into the situation. For example if some FileInputStream with a backing file of length L were used in two different scenarios the results could differ. A) skip(L-4) then skipNBytes(8) B) skip(L) then skipNBytes(4) In case A, skipNBytes(8) could conceivably succeed while in case B, skipNBytes(4) could fail, which is inconsistent given that the final positions in stream terms are theoretically identical. Unclear what to do here ... Thanks, BrianOn Oct 24, 2018, at 4:41 PM, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); "<p>This method may skip more bytes than what are remaining in the * backing file. This produces no exception and the number of bytes skipped * may include some number of bytes that were beyond the EOF of the * backing file. Attempting to read from the stream after skipping past * the end will result in -1 indicating the end of the file."
