[Bug libstdc++/26250] New: stringbuf::overflow() fails to set egptr() same as epptr()

[Bug libstdc++/26250] New: stringbuf::overflow() fails to set egptr() same as epptr()

[sebor at roguewave dot com]

AFAICT, the program below should run successfully to completion.

$ cat -n u.cpp && g++ u.cpp -static && ./a.out
     1  #include <cassert>
     2  #include <sstream>
     3  
     4  struct pubbuf: std::stringbuf {
     5      using std::stringbuf::eback;
     6      using std::stringbuf::egptr;
     7      using std::stringbuf::pbase;
     8      using std::stringbuf::pptr;
     9      using std::stringbuf::epptr;
    10      using std::stringbuf::overflow;
    11  };
    12  
    13  int main ()
    14  {
    15      struct: std::stringbuf { 
    16          using std::stringbuf::eback;
    17          using std::stringbuf::egptr;
    18          using std::stringbuf::pbase;
    19          using std::stringbuf::pptr;
    20          using std::stringbuf::epptr;
    21          using std::stringbuf::overflow;
    22      } buf;
    23  
    24      // 27.7.1.1, p1 and 27.5.2.1, p1:
    25      assert (0 == buf.pbase () && 0 == buf.pptr () && 0 == buf.epptr
());
    26  
    27      // 27.7.1.3, p5, bullet 1:
    28      assert ('x' == buf.overflow ('x'));
    29  
    30      // 27.7.1.3, p5, bullet 1 and 27.5.2.2.5, p1:
    31      assert (1 == buf.pptr () - buf.pbase ());
    32  
    33      // not required but good for efficiency:
    34      const int write_positions = buf.epptr () - buf.pbase ();
    35      assert (1 < write_positions);
    36  
    37      // 27.7.1.3, p8:
    38      assert (write_positions == buf.egptr () - buf.eback ());
    39  }
    40  
Assertion failed: write_positions == buf.egptr () - buf.eback (), file u.cpp,
line 38
Abort (core dumped)


-- 
           Summary: stringbuf::overflow() fails to set egptr() same as
                    epptr()
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2006-02-13 10:03 -------
Confirmed, thanks!


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-13 10:03:01
               date|                            |


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2006-02-13 10:38 -------
I'm sorry, now I really understand the issue, I think (too much time since my
last changes to this code... ;) I don't think we have a problem, actually, in
the sense that we are implementing DR 169 rather literally, including:

  "Of course, the resolution below requires some handling of simultaneous input
and output since it is no longer possible to update egptr() whenever epptr() is
changed. A possible solution is to handle this in underflow()."

This means that we are updating epptr() in underflow, not earlier, not upon
overflow. Does this way of implementing DR 169 make sense to you?


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #3 from pcarlini at suse dot de  2006-02-13 10:59 -------
(In reply to comment #2)
> This means that we are updating epptr() in underflow, not earlier, not upon
> overflow. Does this way of implementing DR 169 make sense to you?

I want to avoid giving the wrong impression that is only matter of "when". In
fact, our (mine and Nathan's, at least) best interpretation of DR 169 implies
keeping get area and put area separate as much as possible (consistently with
filebuf, by the way): this implies not only that egptr() is not updated to
"match" epptr() upon overflow, but also that, really, doesn't make much sense
talking about it during output. In fact, when input will start, and epptr()
will be finally updated to match reality (i.e., the length of the internal
string) in underflow, almost certainly will not match epptr() anyway.


-- 


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[sebor at roguewave dot com]

------- Comment #4 from sebor at roguewave dot com  2006-02-13 18:12 -------
(In reply to comment #3)
[...]
> keeping get area and put area separate as much as possible (consistently with
> filebuf, by the way): this implies not only that egptr() is not updated to
> "match" epptr() upon overflow, but also that, really, doesn't make much sense
> talking about it during output. In fact, when input will start, and epptr()
> will be finally updated to match reality (i.e., the length of the internal
> string) in underflow, almost certainly will not match epptr() anyway.

Yes. But that doesn't conform to the requirement in 27.7.1.3, p8:

  ...If (mode & ios_base::in) != 0, the function alters the read end pointer
  egptr() to point just past the new write position (as does the write end
  pointer epptr()).

I'm not sure it makes sense yet, but it's there nonetheless. DR 169 doesn't
lift the requirement, it just allows overflow() to make more than one write
position available. Maybe we need a new issue to permit the behavior
implemented by libstdc++.


-- 


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2006-02-13 18:20 -------
(In reply to comment #4)
> Yes. But that doesn't conform to the requirement in 27.7.1.3, p8:
> 
>   ...If (mode & ios_base::in) != 0, the function alters the read end pointer
>   egptr() to point just past the new write position (as does the write end
>   pointer epptr()).
> 
> I'm not sure it makes sense yet, but it's there nonetheless. DR 169 doesn't
> lift the requirement, it just allows overflow() to make more than one write
> position available.

I see what you mean. The problem is that DR 169 says that:

"Of course, the resolution below requires some handling of simultaneous input
and output since it is no longer possible to update egptr() whenever epptr() is
changed. A possible solution is to handle this in underflow()."

but then, doesn't change 27.7.1.3, p8, as it should, in my opinion, because the
rationale is exactly that.

                           Maybe we need a new issue to permit the behavior
> implemented by libstdc++.

I would like that ;) Seriously, I think it's already *in* DR 169, only should
be clearly stated, as a change to 27.7.1.3, p8. I don't know which is the best
way to proceed... (by the way, again, Dinkum delivered with ICC also fails the
last assert)


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pcarlini at suse dot de     |unassigned at gcc dot gnu
                   |                            |dot org
             Status|WAITING                     |NEW


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #6 from pcarlini at suse dot de  2006-02-13 18:30 -------
By the way, in my reading of the standard and DR 169, not only the bits about
egptr() in 27.7.1.3, p8 should be consistently updated, but also those about
epptr(), "... just past the new write position (as does the write end pointer
epptr()": if we allow for more than one additional write position, the latter
cannot be always true.


-- 


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[sebor at roguewave dot com]

------- Comment #7 from sebor at roguewave dot com  2006-02-13 18:36 -------
Subject: Re:  stringbuf::overflow() fails to set egptr()
 same as epptr()

pcarlini at suse dot de wrote:
> ------- Comment #6 from pcarlini at suse dot de  2006-02-13 18:30 -------
> By the way, in my reading of the standard and DR 169, not only the bits about
> egptr() in 27.7.1.3, p8 should be consistently updated, but also those about
> epptr(), "... just past the new write position (as does the write end pointer
> epptr()": if we allow for more than one additional write position, the latter
> cannot be always true.

I was afraid of that...


-- 


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[paolo at gcc dot gnu dot org]

------- Comment #8 from paolo at gcc dot gnu dot org  2006-02-17 10:47 -------
Subject: Bug 26250

Author: paolo
Date: Fri Feb 17 10:46:57 2006
New Revision: 111177

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111177
Log:
2006-02-17  Paolo Carlini  <pcarlini@suse.de>
            Howard Hinnant  <hhinnant@apple.com>

        PR libstdc++/26250
        * include/bits/sstream.tcc (basic_stringbuf<>::overflow): Tweak
        to leave epgtr() just past the new write position, as per the
        relevant bits of 27.7.1.3/8 (not changed by DR 432).
        * testsuite/27_io/basic_stringbuf/overflow/char/26250.cc: New.
        * testsuite/27_io/basic_stringbuf/overflow/wchar_t/26250.cc: Same.

        * docs/html/ext/howto.html: Add entries for DR 169 and DR 432.

        * include/std/std_sstream.h (basic_stringbuf<>::_M_sync): Move out
        of line...
        * include/bits/sstream.tcc: ... here.

Added:
    trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/overflow/char/26250.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/overflow/wchar_t/26250.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/docs/html/ext/howto.html
    trunk/libstdc++-v3/include/bits/sstream.tcc
    trunk/libstdc++-v3/include/std/std_sstream.h


-- 


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

[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

[pcarlini at suse dot de]

------- Comment #9 from pcarlini at suse dot de  2006-02-17 10:49 -------
Fixed for 4.2.0.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


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