[RFC] Big troubles with seek & unbuffered filebuf

[Paolo Carlini]

Hi,

in the middle of my work, I stumbled upon this basic problem.
Consider the following testcase ('unbufseek.cc'), current
mainline:

/***************************
//234567890

#include <fstream>
#include <cassert>

const char name_01[] = "unbufseek.cc";

int main()
{
  using namespace std;

  typedef filebuf::int_type     int_type;
  int_type             c1;

  filebuf fb_01;
  fb_01.pubsetbuf(0, 0);
  fb_01.open(name_01, ios::in);

  fb_01.sgetc();
  fb_01.pubseekoff(10, std::ios_base::cur);

  c1 = fb_01.sgetc();
  assert( c1 == '0' );
}
/****************************

If either the first sgetc() or the seekoff are commented out,
the test passes, otherwise doesn't.

The reason is simple: if we try to 'unget' internally the sgetc()
char the file position is actually one char forward than we
think it is. IMHO, this problem pretty much kills any simple
solution, I mean whatever I have already presented and current
mainline.

In my local tree, I have something more complicated which tries
to compensate for this issue, seems almost complete now,
(you will find it attached) but before trying to finalize it I
wanted to ask your opinion about the issue.

By the way, only half seriously, my naive patch of a couple days
ago, involving a seekoff(-1, ...)
(http://gcc.gnu.org/ml/libstdc++/2003-06/msg00062.html)
of course is not affected by the problem.

Thanks, Paolo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_unbuf.gz
Type: application/x-tar
Size: 5166 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030608/28c56d02/attachment.tar>