Hi Brian,
If skip(n) returns a negative number, e.g. -1, then you might
end up skipping more than n bytes (unless skip returning
-1 indicates that EOF was reached).
Basically, I don't think you can make any guarantee of how
many bytes will be skipped if a subclass has an implementation
of skip that misbehave by returning -1 (or any other negative
value).
Maybe there should be some @implSpec note to say that
no guarantee is made if a subclass implementation of
skip() returns non-positive (or non accurate) results?
best regards,
-- daniel
On 01/11/2018 22:24, Brian Burkhalter wrote:
Let’s try this again:
http://cr.openjdk.java.net/~bpb/6516099/webrev.04/
<http://cr.openjdk.java.net/~bpb/6516099/webrev.04/>
The method skipNBytes(long) is now defined in terms of the skip(n) and read(n)
with the behavior for negative n being left open for subclasses.
Thanks,
Brian
On Oct 25, 2018, at 7:15 AM, Roger Riggs <roger.ri...@oracle.com> wrote:
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?
