stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Updated: (STDCXX-243) std::basic_istream::gcount() returns wrong value after a successful peek()
Date Sun, 06 Apr 2008 23:36:24 GMT

     [ https://issues.apache.org/jira/browse/STDCXX-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martin Sebor updated STDCXX-243:
--------------------------------

              Severity: Incorrect Behavior
           Description: 
Moved from the Rogue Wave bug tracking database:

Class/File: istream.cc
Fix Priority: Should Fix
Long Description: 
  \*** Sep 23 1999 9:52AM *** sebor ***

Partially resolved - gcount now more consistent with other implementations (still needs to
be revisited when WG21 addresses the issue - can't find it on the issues list, though).

  \*** Aug 24 1999 9:51AM *** sebor ***

RW implementation of gcount() currently returns 1 after a successful peek(), 0 after an error.
That's wrong according to 27.6.1.3, p2, since peek() doesn't extract any characters. The correct
behavior is either to have gcount() always return 0 after a peek() or not to have peek() affect
gcount() at all. The standard doesn't seem to specify which.

{quote}
To: C++ libraries mailing list
Message c++std-lib-6965

Should basic_istream::peek() affect the value returned by
basic_istream::gcount()?  If it does affect gcount in any
way, then clearly it ought to always set gcount to zero.
The description in 27.6.1.3 [lib.istream.unformatted],
paragraph 27, doesn't say whether peek affects gcount.

Another way to phrase this issue: is peek() an unformatted input
function?  Textually it's located in [lib.istream.unformatted],
but that doesn't mean very much since that section also
contains several member functions that clearly do not behave as
unformatted input functions as described in 27.6.1.3/1.  Textual
location is not a sufficient guide.

Survey:
  Classic AT&T:        peek doesn't affect gcount
  SGI (MIPSpro 7.3):   peek doesn't affect gcount
  Microsoft 6.0:       peek sets gcount to zero.
  Dietmar:             peek sets gcount to zero.
  others?


			--Matt
{quote}
Here's a test program.
{noformat}
#include <stdio.h>
#include <assert.h>
#include <string.h>

#ifndef CLASSIC_IOSTREAMS
#include <iostream>
#include <fstream>
using std::cout;
using std::endl;
using std::ifstream;
using std::ofstream;
#else
#include <iostream.h>
#include <fstream.h>
#endif

int main()
{
  // Create a temporary file.
  char name_buf[L_tmpnam];
  const char* name = tmpnam(name_buf);
  assert(name != 0 && strlen(name) > 0);

  {
    ofstream out(name);
    out << "1234 abcd" << endl;
  }


  {
    ifstream in(name);
    const int N = 128;
    char buf[N];

    in.read(buf, 6);
    assert(in.gcount() == 6);
    assert(strncmp(buf, "1234 a", 6) == 0);

    // The real point of this test: what about peek and gcount?
    assert(in.peek() == 'b');

    cout << "gcount = " << in.gcount() << endl;
  }

  // Destroy the temporary file.
  remove(name);
}
{noformat}

  was:
Moved from the Rogue Wave bug tracking database:

Class/File: istream.cc
Fix Priority: Should Fix
Long Description: 
  *** Sep 23 1999 9:52AM *** sebor ***

Partially resolved - gcount now more consistent with other implementations (still needs to
be revisited when WG21 addresses the issue - can't find it on the issues list, though).

  *** Aug 24 1999 9:51AM *** sebor ***

RW implementation of gcount() currently returns 1 after a successful peek(), 0 after an error.
That's wrong according to 27.6.1.3, p2, since peek() doesn't extract any characters. The correct
behavior is either to have gcount() always return 0 after a peek() or not to have peek() affect
gcount() at all. The standard doesn't seem to specify which.

To: C++ libraries mailing list
Message c++std-lib-6965

Should basic_istream::peek() affect the value returned by
basic_istream::gcount()?  If it does affect gcount in any
way, then clearly it ought to always set gcount to zero.
The description in 27.6.1.3 [lib.istream.unformatted],
paragraph 27, doesn't say whether peek affects gcount.

Another way to phrase this issue: is peek() an unformatted input
function?  Textually it's located in [lib.istream.unformatted],
but that doesn't mean very much since that section also
contains several member functions that clearly do not behave as
unformatted input functions as described in 27.6.1.3/1.  Textual
location is not a sufficient guide.

Survey:
  Classic AT&T:        peek doesn't affect gcount
  SGI (MIPSpro 7.3):   peek doesn't affect gcount
  Microsoft 6.0:       peek sets gcount to zero.
  Dietmar:             peek sets gcount to zero.
  others?


			--Matt

Here's a test program.

#include <stdio.h>
#include <assert.h>
#include <string.h>

#ifndef CLASSIC_IOSTREAMS
#include <iostream>
#include <fstream>
using std::cout;
using std::endl;
using std::ifstream;
using std::ofstream;
#else
#include <iostream.h>
#include <fstream.h>
#endif

int main()
{
  // Create a temporary file.
  char name_buf[L_tmpnam];
  const char* name = tmpnam(name_buf);
  assert(name != 0 && strlen(name) > 0);

  {
    ofstream out(name);
    out << "1234 abcd" << endl;
  }


  {
    ifstream in(name);
    const int N = 128;
    char buf[N];

    in.read(buf, 6);
    assert(in.gcount() == 6);
    assert(strncmp(buf, "1234 a", 6) == 0);

    // The real point of this test: what about peek and gcount?
    assert(in.peek() == 'b');

    cout << "gcount = " << in.gcount() << endl;
  }

  // Destroy the temporary file.
  remove(name);
}

     Affects Version/s: 4.1.4
                        4.2.0
         Fix Version/s: 4.2.2
    Remaining Estimate: 6h
     Original Estimate: 6h

Fixed formatting, set Severity, scheduled for 4.2.2, and took a conservative guess and the
effort required in fixing this.

> std::basic_istream::gcount() returns wrong value after a successful peek()
> --------------------------------------------------------------------------
>
>                 Key: STDCXX-243
>                 URL: https://issues.apache.org/jira/browse/STDCXX-243
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: 27. Input/Output
>    Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
>         Environment: all
>            Reporter: Martin Sebor
>            Assignee: Martin Sebor
>             Fix For: 4.2.2
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> Moved from the Rogue Wave bug tracking database:
> Class/File: istream.cc
> Fix Priority: Should Fix
> Long Description: 
>   \*** Sep 23 1999 9:52AM *** sebor ***
> Partially resolved - gcount now more consistent with other implementations (still needs
to be revisited when WG21 addresses the issue - can't find it on the issues list, though).
>   \*** Aug 24 1999 9:51AM *** sebor ***
> RW implementation of gcount() currently returns 1 after a successful peek(), 0 after
an error. That's wrong according to 27.6.1.3, p2, since peek() doesn't extract any characters.
The correct behavior is either to have gcount() always return 0 after a peek() or not to have
peek() affect gcount() at all. The standard doesn't seem to specify which.
> {quote}
> To: C++ libraries mailing list
> Message c++std-lib-6965
> Should basic_istream::peek() affect the value returned by
> basic_istream::gcount()?  If it does affect gcount in any
> way, then clearly it ought to always set gcount to zero.
> The description in 27.6.1.3 [lib.istream.unformatted],
> paragraph 27, doesn't say whether peek affects gcount.
> Another way to phrase this issue: is peek() an unformatted input
> function?  Textually it's located in [lib.istream.unformatted],
> but that doesn't mean very much since that section also
> contains several member functions that clearly do not behave as
> unformatted input functions as described in 27.6.1.3/1.  Textual
> location is not a sufficient guide.
> Survey:
>   Classic AT&T:        peek doesn't affect gcount
>   SGI (MIPSpro 7.3):   peek doesn't affect gcount
>   Microsoft 6.0:       peek sets gcount to zero.
>   Dietmar:             peek sets gcount to zero.
>   others?
> 			--Matt
> {quote}
> Here's a test program.
> {noformat}
> #include <stdio.h>
> #include <assert.h>
> #include <string.h>
> #ifndef CLASSIC_IOSTREAMS
> #include <iostream>
> #include <fstream>
> using std::cout;
> using std::endl;
> using std::ifstream;
> using std::ofstream;
> #else
> #include <iostream.h>
> #include <fstream.h>
> #endif
> int main()
> {
>   // Create a temporary file.
>   char name_buf[L_tmpnam];
>   const char* name = tmpnam(name_buf);
>   assert(name != 0 && strlen(name) > 0);
>   {
>     ofstream out(name);
>     out << "1234 abcd" << endl;
>   }
>   {
>     ifstream in(name);
>     const int N = 128;
>     char buf[N];
>     in.read(buf, 6);
>     assert(in.gcount() == 6);
>     assert(strncmp(buf, "1234 a", 6) == 0);
>     // The real point of this test: what about peek and gcount?
>     assert(in.peek() == 'b');
>     cout << "gcount = " << in.gcount() << endl;
>   }
>   // Destroy the temporary file.
>   remove(name);
> }
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message