4

I'm trying to find more about history of java.io.FileInputStream.skip(n) operation when n is negative. According to InputStream documentation:

If n is negative, no bytes are skipped.

It seems that implementation of FileInputStream from Sun used to throw IOException instead, which is now also documented in Javadoc:

If n is negative, an IOException is thrown, even though the skip method of the InputStream superclass does nothing in this case.

I just tried that, and found that FileInputStream.skip(-10) did in fact return -10! It didn't threw exception, it didn't even return 0, it returned -10. (I've tried with Java 1.5.0_22 from Sun, and Java 1.6.0_18 from Sun).

Is this a known bug? Why hasn't it been fixed, or why documentation is kept the way it is? Can someone point me to some discussion about this issue? I can't find anything.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Peter Štibraný
  • 32,463
  • 16
  • 90
  • 116
  • Maybe it is related to these lines in documentation: This method may skip more bytes than 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. I tried it in scrapbook and I am getting IOException with proper message. BTW. never thought to run into you here:) – Gabriel Ščerbák Mar 11 '10 at 19:50
  • ...I was trying it out with jdk1.6.0_13 – Gabriel Ščerbák Mar 11 '10 at 20:03
  • 1
    If the InputStream documentation specifically says "If n is negative, no bytes are skipped", but FileInputStream skips, then it looks like a bug. Either in the documentation or the implementation. – user253751 Oct 12 '15 at 02:05

1 Answers1

1

The acutal implementation of SocketInputStream gives the answer:

  public long skip(long numbytes) throws IOException {
        if (numbytes <= 0) {
            return 0;
        }
  ...
  }

EDIT: Sorry, I examined the wrong class FileInputStreams implementation is native this is the implementation in openjdk7

if ((cur = IO_Lseek(fd, (jlong)0, (jint)SEEK_CUR)) == -1) {
        JNU_ThrowIOExceptionWithLastError(env, "Seek error");
    } else if ((end = IO_Lseek(fd, toSkip, (jint)SEEK_CUR)) == -1) {
        JNU_ThrowIOExceptionWithLastError(env, "Seek error");
    }
    return (end - cur);
stacker
  • 68,052
  • 28
  • 140
  • 210
  • The question concerns FileInputStream. – user207421 Mar 12 '10 at 02:01
  • 1
    @Stacker, thank you for taking the time to lookup the implementation in openjdk7. I was curious about it too, but I'm mostly interested in *why* it works the way it does. I mean, is there any reason to allow negative values if documentation says they should cause IOException? – Peter Štibraný Mar 12 '10 at 15:44
  • @Peter Štibraný http://linux.die.net/man/2/lseek - Even the system call says nothing to valid ranges, maybe it's OS-dependend if you can seek behind EOF it could also be possible to seek before the beginning of a file. But I don't have the time to have look into the linux kernel. – stacker Mar 12 '10 at 16:59
  • 1
    Don't bother with low level stuff. I am really interested in **reason why Java implementation doesn't throw IOException as documented in Javadoc comment**. Anyway, thank you :-) (I've now filled bug report in Sun/Oracle database) – Peter Štibraný Mar 12 '10 at 17:25