[
https://issues.apache.org/jira/browse/STDCXX-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-243:
--------------------------------
Priority: Minor (was: Major)
Lowered Priority to Minor.
> 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
> Priority: Minor
> 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.
