public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "brendan at zen dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/10975] incorrect initial ostringstream::tellp()
Date: Thu, 17 Jul 2003 16:19:00 -0000	[thread overview]
Message-ID: <20030717161913.12650.qmail@sources.redhat.com> (raw)
In-Reply-To: <20030526002442.10975.from-bugzilla@geek-central.gen.nz>

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From brendan at zen dot org  2003-07-17 16:19 -------
  The -1 that's being received from tellp() is happening because of what's
  being given back by pubseekoff(); that, in turn, is giving the correct
  value.

  In pubseekoff() it calls this->seekoff(), which in sstream.tcc sets up to
  only do anything if its _M_string.capacity() is > 0.

 template <class _CharT, class _Traits, class _Alloc>
    typename basic_stringbuf<_CharT, _Traits, _Alloc>::pos_type
    basic_stringbuf<_CharT, _Traits, _Alloc>::
    seekoff(off_type __off, ios_base::seekdir __way, ios_base::openmode __mode)
    {
       pos_type __ret =  pos_type(off_type(-1)); 
       //...
       if (_M_string.capacity() && (__testin || __testout || __testboth))
	 {
	 //...
	 }
       return __ret;
    }

  Otherwise the method goes out with the default pos_type value of -1.  (see
  below for a note about this)

  To figure out why we might not have anything allocated for the basic_string
  object being used here, we can to dive head-first into the standard to find
  out about the ostringstream object we're using.

  In $27.7.3 it says that basic_ostringstream uses a basic_stringbuf object to
  control the associated storage.

  Looking up basic_stringbuf, in $27.7.1.1.2/1 it notes that the
  basic_stringbuf default ctor "allocates no array object".  Thus by default,
  the capacity of the string will be 0.

  As such, since there's no space yet for seekoff() to move inside the
  basic_stringbuf, it gives back the -1 value which tellp() relays to the call
  in the testcase.

  Thus I believe the library's actually behaving correctly in this example.

  Hope this helps,
  B

  P.S. The returning of -1 isn't precisely what's said in the current
  published standard.  The library working group's Defect Report 55 as seen in
     http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#55
  adjusts the standard after the fact to say in 27.7.1.3 paragraph 13 about
  basic_stringbuf's seekoff() method:
      the return value is pos_type(off_type(-1))
  instead of
      the object stores an invalid stream position
  That DR was just a clarification across the board, and isn't really a part
  of this issue.


  parent reply	other threads:[~2003-07-17 16:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-26  0:31 [Bug c++/10975] New: " from-bugzilla@geek-central.gen.nz
2003-05-26  1:07 ` [Bug c++/10975] " pinskia@physics.uc.edu
2003-06-22  3:24 ` [Bug libstdc++/10975] " pinskia at physics dot uc dot edu
2003-07-17 16:19 ` brendan at zen dot org [this message]
2003-07-18  8:58 ` from-bugzilla at geek-central dot gen dot nz
2003-12-30 22:54 ` jlquinn at optonline dot net
2004-01-02  2:12 ` ncm-nospam at cantrip dot org
2004-01-02  2:36 ` pinskia at gcc dot gnu dot org
2004-04-18  2:25 ` pinskia at gcc dot gnu dot org
2004-04-18  2:51 ` pinskia at gcc dot gnu dot org
2004-05-28 23:06 ` drgreening at yahoo dot com
2004-08-05 11:50 ` [Bug libstdc++/10975] [DR 453] " pcarlini at suse dot de
2004-09-30 17:23 ` cvs-commit at gcc dot gnu dot org
2004-09-30 17:28 ` [Bug libstdc++/10975] [3.4 only] " pcarlini at suse dot de
2004-10-05 19:50 ` cvs-commit at gcc dot gnu dot org
2004-10-05 19:52 ` pcarlini at suse dot de

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030717161913.12650.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).