------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
