Summary: | NPOIFSFileSystem seems to parse row numbers as signed | ||
---|---|---|---|
Product: | POI | Reporter: | Antoni Mylka <antoni.mylka> |
Component: | HSSF | Assignee: | POI Developers List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 3.8-dev | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: |
A test document and a junit test case which exposes the issue
A patch which seems to fix the issue |
I've added a slightly tweaked version of your unit test in r1149181. It's currently disabled as the test fails as described Created attachment 27373 [details]
A patch which seems to fix the issue
NDocumentInputStream.readUShort() method would delegate to LittleIndian.getShort(). I changed this to LittleIndian.getUShort(). Nothing else broke, so the lack of 'U' must have been a typo.
|
Created attachment 27303 [details] A test document and a junit test case which exposes the issue When I have a document with data in rows with a high number (say 65535) I get array index exceptions because row numbers are negative. For instance in ValueRecordsAggregate in line CellValueRecordInterface[] rowCells = records[row]; row is -32768 moreover in HSSFSheet while (row != null) { createRowFromRecord(row); row = sheet.getNextRow(); } There are cases where row.getRowNumber returns a negative int. I tried to manufacture an example file. It seems that NPOIFS somewhere parses the row number as a signed number, while it has to be unsigned. I don't know enough POI to fix this myself but my test case seems to show the problem. It didn't occur with older POIFS.