Hi Brian,
Looks good to me, though I don't understand the change
at line 214:
The comment says:
152 // skip(n) returns negative value: IOE
but if you pass -1 - you're no longer calling skip(n)?
best regards,
-- daniel
On 30/11/2018 19:55, Brian Burkhalter wrote:
Loathe though I am to resurrect this thread, one problem arose after testing
with assertions enabled which I had neglected previously to do. A few small
changes to test/jdk/java/io/InputStream/Skip.java are required. A delta versus
webrev.08 (link at bottom) is at
http://cr.openjdk.java.net/~bpb/6516099/webrev.08-delta/
The changes are as follows (line numbers in the new version):
1. L154
in.setState(-1, 100);
- dotestExact(in, pos, streamLength, n, true, false);
+ dotestExact(in, pos, streamLength, -1, true, false);
Pass “-1” as the number to skip instead of “n.”
2. L159
in.setState(n + 1, 100);
dotestExact(in, pos, streamLength, n, true, false);
+ pos += n + 1;
Update the test-tracked position according to the number actually skipped,
which is “n + 1” although only “n” bytes were requested. This sub-test causes
the internal call to “skip()” to be “skip(n+1)” which will return “n+1” which
intentionally provokes an IOException and leaves the stream in an inconsistent
state as documented. The call to “skip(n+1)” does however really skip “n+1”
bytes so the test-tracked position must be updated accordingly.
3. L214
- public long position() { return readctr == endoffile ? EOF : readctr; }
+ public long position() { return readctr; }
The position should be returning the actual offset which for EOF is the length
of the stream, not -1.
With the foregoing changes the test passes.
Thanks,
Brian
On Nov 28, 2018, at 9:51 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
Looks good to me Brian.
I never knew whether positive meant >= 0 or > 0 anyway ;-)
best regards,
-- daniel
On 28/11/2018 17:38, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/6516099/webrev.08/
