[Bug libstdc++/10975] incorrect initial ostringstream::tellp()

["jlquinn at optonline dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jlquinn at optonline dot net  2003-12-30 22:16 -------
(In reply to comment #3) 
> That's an implementation issue. I don't see why such implementation 
> issues should cause a difference in the semantics. Consider: the 
> ostream object is fully initialized and ready for use. Nothing has been 
> written to it yet. Therefore the output position should be 0. This is true if 
> output is going to a file, why shouldn't it be true for output going to a 
> string?

Unfortunately this isn't an implementation issue.  Consider the following
according to the standard:

For ofstream:

ofstream os("junk");
os.tellp();

1) ofstream(const char*) constructs a basic_filebuf and opens "junk"
2) ofstream::tellp() returns rdbuf()->pubseekoff(0, cur, out)
3) basic_streambuf::pubseekoff(0, cur, out) returns basic_filebuf::seekoff(0,
cur, out)
4) basic_filebuf::seekoff(0, cur, out) does:
 width = codecvt.encoding()
 if !is_open() return -1
 std::fseek(file, 0, cur)
 return new position [which is 0]

Now consider ostringstream:

ostringstream os;
os.tellp();

1) ostringstream() constructs basic_stringbuf.
2) basic_stringbuf() constructs basic_streambuf but allocates no array object
 and sets pointers to null.
3) ostringstream::tellp() returns basic_streambuf::pubseekoff(0, cur, out)
4) basic_streambuf::pubseekoff(0, cur, out) returns
 basic_stringbuf::seekoff(0, cur, out)
5) basic_stringbuf::seekoff(0, cur, out) does:
 if pptr() == null return -1

Since the basic_stringbuf has no array object yet and its pointers are null,
basic_streambuf::pptr() returns null, and the final return value must be -1.

FWIW, I agree this is less than intuitive, but seems correct according to the
standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10975