public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/2627
@ 2001-05-02 11:06 bkoz
  0 siblings, 0 replies; 5+ messages in thread
From: bkoz @ 2001-05-02 11:06 UTC (permalink / raw)
  To: bkoz; +Cc: gcc-prs

The following reply was made to PR libstdc++/2627; it has been noted by GNATS.

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  johnw@mp-dhcp-4-40.attlabs.att.com, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/2627
Date: 2 May 2001 17:58:33 -0000

 Synopsis: istreambuf_iterator fails to satisfy input iterator requirements
 
 Responsible-Changed-From-To: unassigned->bkoz
 Responsible-Changed-By: bkoz
 Responsible-Changed-When: Wed May  2 10:58:33 2001
 Responsible-Changed-Why:
     Responsible
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: bkoz
 State-Changed-When: Wed May  2 10:58:33 2001
 State-Changed-Why:
     Fixed with this:
     
     2001-05-01  Benjamin Kosnik  <bkoz@redhat.com>
     
     	* include/bits/sbuf_iter.h (istreambuf_iterator): Correct.
     	* testsuite/24_iterators/istreambuf_iterator.cc (test02): Add test.
     
     	* include/bits/std_sstream.h (stringbuf): Leak
     	copied string.
     	* testsuite/24_iterators/ostreambuf_iterator.cc: Correct.
     
     
     and
     
     2001-04-30  Benjamin Kosnik  <bkoz@redhat.com>
     
     	libstdc++/2627 
     	* testsuite/24_iterators/ostreambuf_iterator.cc: New file.
     	* include/bits/sbuf_iter.h (ostreambuf_iterator): Remove bogus
     	specializations.
     
     
     In addition, some ostreambuf_iterator bits were fixed. Test cases were added for both: thanks for your bug report.
     
     -benjamin
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2627&database=gcc


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: libstdc++/2627
@ 2001-05-08 23:46 bkoz
  0 siblings, 0 replies; 5+ messages in thread
From: bkoz @ 2001-05-08 23:46 UTC (permalink / raw)
  To: bkoz; +Cc: gcc-prs

The following reply was made to PR libstdc++/2627; it has been noted by GNATS.

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  johnw@mp-dhcp-4-40.attlabs.att.com
Cc:  
Subject: Re: libstdc++/2627
Date: 9 May 2001 06:40:20 -0000

 Synopsis: istreambuf_iterator fails to satisfy input iterator requirements
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bkoz
 State-Changed-When: Tue May  8 23:40:19 2001
 State-Changed-Why:
     Fixed
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2627&database=gcc


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: libstdc++/2627
@ 2001-04-25 10:56 Matthew Austern
  0 siblings, 0 replies; 5+ messages in thread
From: Matthew Austern @ 2001-04-25 10:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR libstdc++/2627; it has been noted by GNATS.

From: Matthew Austern <austern@research.att.com>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
        johnw@mp-dhcp-4-40.attlabs.att.com
Cc:  
Subject: Re: libstdc++/2627
Date: Wed, 25 Apr 2001 10:46:10 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2627&database=gcc
 
 I think the response misses the relevant part of
 the C++ standard.  What's important is not the 
 introduction in 24.5.3, but the specific description 
 of operator++ in 24.5.3.4 [lib.istreabuf.iterator::op++].
 
 24.5.3.4/1 says that operator++() is supposed to 
 call sbumpc() on the underlying streambuf, and
 24.5.3.4/3 says that operator++(int) is supposed
 to call sbumpc() as well.
 
 			--Matt


^ permalink raw reply	[flat|nested] 5+ messages in thread

* libstdc++/2627
@ 2001-04-25  7:36 John Wilkinson
  0 siblings, 0 replies; 5+ messages in thread
From: John Wilkinson @ 2001-04-25  7:36 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR libstdc++/2627; it has been noted by GNATS.

From: John Wilkinson <johnw@research.att.com>
To: gcc-gnats@gcc.gnu.org
Cc: austern@research.att.com
Subject: libstdc++/2627
Date: Wed, 25 Apr 2001 07:28:35 -0400

 Thank you for your reply.  I'm sorry I reported the output incorrectly.
 It is indeed abb.  If this is what the standard requires, then it is a
 defect in the standard, since the equivalence of x++ and ++x is one of
 the requirements for input iterators (24.1.1).   If it is violated, then
 one cannot rely on algorithms written to the standard.  I will bring
 this up with the C++ library group.
 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: libstdc++/2627
@ 2001-04-25  5:26 pme
  0 siblings, 0 replies; 5+ messages in thread
From: pme @ 2001-04-25  5:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR libstdc++/2627; it has been noted by GNATS.

From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, johnw@mp-dhcp-4-40.attlabs.att.com,
  nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/2627
Date: 25 Apr 2001 12:25:35 -0000

 Synopsis: istreambuf_iterator fails to satisfy input iterator requirements
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: pme
 State-Changed-When: Wed Apr 25 05:25:35 2001
 State-Changed-Why:
     Thank you for your bug report.
     
     I don't believe that pre-inc and post-inc are required to
     be equivalent operations on istreambuf_iterators, even
     though it is an input iterator.  A couple of points:
     
        [24.5.3/1]:
        # operator* provides access to the current input
        # character, if any. Each time operator++ is evaluated,
        # the iterator advances to the next input character.
     
     operator++(int) is not mentioned there; there is no
     requirement that the iterator advances.
     
         [24.5.3.1]/1:
         # Class istreambuf_iterator<charT,traits>::proxy
         # provides a temporary placeholder as the return value
         # of the post-increment operator (operator++). It keeps
         # the character pointed to by the previous value of
         # the iterator for some possible future access to get
         # the character.
     
     Here, clearly the character is meant to be stored and
     buffered.
     
     However, I don't get "aab".  Using gcc version 3.0 20010425
     I get
     
         11% g++ -Wall -W 2627.cc
         12% ./a.out
         a
         b
         b
         13%
     
     which is what I /think/ is required by the standard.  Not
     sure on this one; we need an expert's opinion.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2627&database=gcc


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-05-08 23:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-02 11:06 libstdc++/2627 bkoz
  -- strict thread matches above, loose matches on Subject: below --
2001-05-08 23:46 libstdc++/2627 bkoz
2001-04-25 10:56 libstdc++/2627 Matthew Austern
2001-04-25  7:36 libstdc++/2627 John Wilkinson
2001-04-25  5:26 libstdc++/2627 pme

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).