Hi,
The FIS skipping past of end of file is puzzling.
If the 'were beyond EOF' was considering the possibility that the file
was being
extended concurrently with the skip operation then it would not be random,
just a normal writer/reader race. The return value from skip would be
accurate
and still usable for skipNBytes.
If the spec for skipNBytes describes its behavior in terms of the normal
behaviors
of skip(n) and read(n) then it will not making promises it can't keep
regardless of the subclass behavior.
FIS also says it can do negative seeks which seems in conflict with
InputStream.
The FIS.skip(-n) behavior raises the question about whether
InputStream.skipNBytes should
allow -n?
Roger
p.s.
There are 200+ subclasses of InputStream in the JDK itself so trying to
figure out which ones should have performant versions of skipNBytes
would be quite a bit of extra work.
On 10/24/2018 08:14 PM, 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,
Brian
On 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."
