Message9692
Huh. Looks like this is caused by optimization in the way we buffer file read operations. fd.read(1) does not strictly read only one byte from the underlying java.nio.channels.FileChannel object.
Jython's fd.read() (where fd is returned by file() built-in function) is dispatched to PyFile#file_read method. Eventually, the read operation is done by calling FileChannel#read(ByteBuffer[] dsts) scattered IO read where the first byte buffer is the one returned to the caller (in this case of size 1), but there exists a secondary byte buffer that will be filled with the rest of the file.
So in the case of the test case above, when we're at, say, position 253 and call fd.read(1), we'll get the 254th byte as read, but the underlying file channel has been read all the way to the end. Hence, fd.seek(-1, SEEK_CUR) having the surprising result. |
|
Date |
User |
Action |
Args |
2015-03-21 02:15:40 | santa4nt | set | messageid: <1426904140.5.0.0314386932085.issue1793@psf.upfronthosting.co.za> |
2015-03-21 02:15:40 | santa4nt | set | recipients:
+ santa4nt, fwierzbicki, zyasoft, tuck182 |
2015-03-21 02:15:40 | santa4nt | link | issue1793 messages |
2015-03-21 02:15:39 | santa4nt | create | |
|