[ 
https://issues.apache.org/jira/browse/PDFBOX-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fredrik Kjellberg updated PDFBOX-1582:
--------------------------------------

    Attachment: TestRandomAccessFileInputStream_diff.txt
    
> Issues with available() and skip() on RandomAccessFileInputStream
> -----------------------------------------------------------------
>
>                 Key: PDFBOX-1582
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-1582
>             Project: PDFBox
>          Issue Type: Test
>          Components: Parsing
>    Affects Versions: 1.8.1
>            Reporter: Fredrik Kjellberg
>            Priority: Minor
>         Attachments: TestRandomAccessFileInputStream_diff.txt
>
>
> I'm trying to track down a strange bug when parsing PDF files on the IBM JDK 
> that sometimes is giving me stack traces from RandomAccessFile classes. I 
> started by writing unit tests for the PDFBox classes to verify their behavior 
> and found a few issues. Can someone more familiar with the PDFBox code base 
> please check the unit test I wrote and give advise on how it is supposed to 
> work? I've added a TODO for each line where I'm in doubt what should be 
> returned.
> This unit test is for RandomAccessFileInputStream where I've found a few 
> issues. The first is what available() is supposed to return if the input 
> stream tries to go beyond the EOF of the underlying file? When reading single 
> bytes it count down while still returning -1 and when reading a buffer, it is 
> returning what it think is left. The JDK documentation states that 
> available() may not return the absolute truth, so perhaps returning what it 
> think is left is okay, but it shouldn't count down in single reads beyond 
> EOF? Maybe it should be set to zero once a read beyond the EOF is detected?
> Another issue is with skip() where the JDK documentation states that it 
> should return the actual number of bytes skipped. When skipping beyond the 
> EOF of the file, it does not return the actual number of skipped bytes. Also 
> the underlying file is not updated with the new position. Is this correct 
> behavior?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to