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