From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 Description of problem: I ran into two regressions with 3.1: 1. istream::get(char* s, streamsize n ) sets the fail bit for empty lines. 2. Output to stdout is unbuffered. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: See test.C attached to this bug. Compile it, and run it with its own source code on standard input: ./test <test.C Then strace it: strace ./test <test.C Actual Results: Result when compiled with gcc 3.1: $ ./test <test.C count: 19 get: 10 fail: 0 bad: 0 good: 1 count: 0 get: -1 fail: 1 bad: 0 good: 0 $ strace ./test <test.C [ ... ] write(1, "b", 1b) = 1 write(1, "a", 1a) = 1 write(1, "d", 1d) = 1 write(1, ":", 1:) = 1 write(1, " ", 1 ) = 1 write(1, "0", 10) = 1 write(1, "\n", 1) = 1 write(1, "g", 1g) = 1 write(1, "o", 1o) = 1 write(1, "o", 1o) = 1 write(1, "d", 1d) = 1 write(1, ":", 1:) = 1 write(1, " ", 1 ) = 1 write(1, "0", 10) = 1 write(1, "\n", 1) = 1 _llseek(0, -551, [20], SEEK_CUR) = 0 munmap(0x40019000, 4096) = 0 _exit(0) = ? Expected Results: Output when compiled with gcc 2.96, and earlier: $ ./test <test.C count: 19 get: 10 fail: 0 bad: 0 good: 1 count: 0 get: 10 fail: 0 bad: 0 good: 1 $ strace ./test <test.C write(1, "get: 10\n", 8) = 8 write(1, "fail: 0\n", 8) = 8 write(1, "bad: 0\n", 7) = 7 write(1, "good: 1\n", 8) = 8 munmap(0x40019000, 4096) = 0 _exit(0) = ? Additional info: http://www.cplusplus.com/ref/iostream/istream/get.html states: istream& get (char* s, streamsize n ); - extracts characters from the stream and stores them into successive locations in the array pointed by s. Characters are extracted until either (n - 1) characters have been extracted, the delimiter (parameter delim or '\n' if not specified) is found, or if the end of file or any error occurs in the input sequence. If the delimiter is found it is not extracted from the input stream and remains as the next character to be extracted. ... therefore after calling get(char *, streamsize), you need to call get() again to get the delimiting \n. Now, the second line in test.C is empty, and gcc 3.1's iostreams apparently sets the fail bit if get reads an empty line, which doesn't make sense, and the subsequent get() returns an end of file condition. Doesn't make sense. I see nothing on cplusplus.com that would indicate that an empty line should be interpreted as a failure condition. When trying to track this one down, I also noticed in strace that output to cout is not buffered at all. Doesn't make sense either.
Created attachment 45640 [details] Test program.
Thanks for your feedback. In the future, it will be helpful if you could try to have one bug per bugreport. It'll help me track progress, thanks. 1. istream::get(char* s, streamsize n ) sets the fail bit for empty lines. This is actually required now. See: 27.6.1.3 - Unformatted input functions Characters are extracted and stored until any of the following occurs: * n - 1 characters are stored; * end-of-file occurs on the input sequence (in which case the function calls setstate(eofbit)); * c == delim for the next available input character c (in which case c is not extracted). If the function stores no characters, it calls setstate(failbit) This last part is why failbit is being set on the stream. 2. Output to stdout is unbuffered. This is correct. By default, stdout is unbuffered. To make it buffered, you'd need to do: ios_base::sync_with_stdio(false); This is not an ideal situation, and I'll work on trying to get this working better.
Closing due to inactivity. Please feel free to reopen this bug or refile this bug against the latest release Fedora Core if you feel this bug is still relevant today. Thank you