
| Key: |
STDCXX-243
|
| Type: |
Improvement
|
| Status: |
Open
|
| Priority: |
Minor
|
| Assignee: |
Unassigned
|
| Reporter: |
Martin Sebor
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Time Tracking:
|
|
Original Estimate:
|
6h
|
|
|
Remaining Estimate:
|
6h
|
|
|
Time Spent:
|
Not Specified
|
|
|
|
| Severity: |
Incorrect Behavior
|
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.
|
|
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.
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.
|
Show » |
made changes - 10/Dec/07 06:46 AM
| Field |
Original Value |
New Value |
|
Assignee
|
|
Martin Sebor
[ sebor
]
|
made changes - 06/Apr/08 11:35 PM
|
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.
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);
}
|
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}
|
|
Severity
|
|
Incorrect Behavior
|
|
Affects Version/s
|
|
4.1.4
[ 12310693
]
|
|
Affects Version/s
|
|
4.2.0
[ 12311945
]
|
|
Fix Version/s
|
|
4.2.2
[ 12313096
]
|
|
Remaining Estimate
|
|
6h
[ 21600
]
|
|
Original Estimate
|
|
6h
[ 21600
]
|
made changes - 05/May/08 05:23 PM
|
Priority
|
Major
[ 3
]
|
Minor
[ 4
]
|
made changes - 02/Dec/08 03:05 AM
|
Assignee
|
Martin Sebor
[ sebor
]
|
|
|