jayduhon / inferno-os

Automatically exported from code.google.com/p/inferno-os
2 stars 0 forks source link

bufio sets wrong iobuf offset after failed seek #199

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. create a dummy file named "testfile0" of 100 bytes.
2. bufio open the file, seek to the middle, offset 50.
3. seek to -8k, this fails because it seeks to before the start of the file
4. call offset().  this claims the offset is 0 (bufio thinks it is 0). 
however it really is the offset from before the failed seek.

What is the expected output? What do you see instead?
attached is a program to test and a patch for appl/lib/bufio.b.

instead of assuming offset 0 after a failed seek, we just request the real
offset and work with that.  another option would be to keep the iobuf in a
"failed" state, but that would require more checking for such a state
throughout the code.  anyway, as it is, offset() happily returns an
incorrect offset 0, that is not very helpful.  even with this patch, if the
seek to find the current offset fails we assume 0.  hopefully that happens
far less often.

the behaviour that a seek to before the start of file leaves the offset
unchanged, and does not set it to offset 0, appears to be the same for plan
9, inferno and openbsd.

the patch also removes the double assignment of the same value.

running the test program without and with the bufio.b patch:

# without patch:
; testbufioseek
seek end-50, o 50
read 40 bytes, from old o 50, new o 90
seeked to end-50 again, o 50
seeked -8k (from end-50), new o -2
seek failed, current offset is 0
tried reading 101 bytes, read 40
tried reading 101 bytes, read 10
tried reading 101 bytes, read 0
final offset 50
;

# with patch:
; testbufioseek
seek end-50, o 50
read 40 bytes, from old o 50, new o 90
seeked to end-50 again, o 50
seeked -8k (from end-50), new o -2
seek failed, current offset is 50
tried reading 101 bytes, read 40
tried reading 101 bytes, read 10
tried reading 101 bytes, read 0
final offset 100
;

Please use labels and text to provide additional information.

Original issue reported on code.google.com by mechiel@ueber.net on 28 Jul 2009 at 9:21

Attachments:

GoogleCodeExporter commented 9 years ago
in bufio.b, in the failing case for sys->seek(), we can perhaps just not touch
b.filpos at all (or perhaps only set b.bufpos to b.filpos), and return error.  
the
filpos should be correct when seek is called.

Original comment by mechiel@ueber.net on 28 Jul 2009 at 9:34

GoogleCodeExporter commented 9 years ago
i've gone for the second suggestion.
the file pointer will be unchanged on either an Enegoff or request to seek on a 
stream.
index and size are now zero, so bufpos should show that buf[0] is at filpos.
i think that's right, and changing the test program to show sys->seek(b.fd, big 
0, 1), 
shows that in that particular case the bufio state is the same as the system's
which seems better than the original behaviour.

Original comment by Charles....@gmail.com on 28 Jul 2009 at 4:59