This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 59871 - Several regression failures in g++ 3.1
Several regression failures in g++ 3.1
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-13 23:52 EST by Sam Varshavchik
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-10 11:30:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program. (571 bytes, text/plain)
2002-02-13 23:53 EST, Sam Varshavchik
no flags Details

  None (edit)
Description Sam Varshavchik 2002-02-13 23:52:16 EST
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.
Comment 1 Sam Varshavchik 2002-02-13 23:53:05 EST
Created attachment 45640 [details]
Test program.
Comment 2 Benjamin Kosnik 2002-02-19 02:48:01 EST
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.







Comment 3 David Lawrence 2006-04-10 11:30:15 EDT
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

Note You need to log in before you can comment on or make changes to this bug.