------- Comment #32 from potswa at mac dot com  2010-09-11 04:49 -------
(In reply to comment #31)
> I'm afraid that the situation I outlined in Comment #5 is just the simple one.
> The real problem with the new scheme - which tries to deal specially with (0,
> cur) by not moving the file pointer - is when *writes* follow the seek. After 
> a
> while the buffer becomes full and must be flushed to the file starting at the
> logical position corresponding to the previous seek. Thus - it seems to me -
> the file pointer must be finally adjusted. How to do that without saving
> anything in the filebuf? (note that within the current ABI we cannot add data
> members)

I don't see how this is particularly difficult. A seekoff(0,ios_cur) operation
should only ever call lseek(0,SEEK_CUR). It does not point the file position
inside the buffer.

For simple byte-oriented case:

read, tell, write: egptr corresponds to to file marker. Tell finds logical
position using gptr-egptr. Write invalidates get area and starts fresh.

write, tell, write: pbase corresponds to file marker. Tell finds logical
position using pptr-pbase. Pointers and marker are still valid for next write.

To handle writes, we simply have to avoid calling _M_seek and overflow.



Reply via email to