Date:	Thu, 22 Apr 1999 17:54:11 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT usa DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bug no. 277
In-Reply-To:	<199904221237.MAA95510@out4.ibm.net>
Message-ID:	<Pine.SUN.3.91.990422174816.11763A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 22 Apr 1999, Mark E. wrote:

> With 'int q' and clearerr(stdin), the program doesn't work correctly.
> With 'char q' and no clearerr(stdin), same.
> With 'char q' and clearerr(stdin), the program works.

Thanks for clarifying this.

> My second report was based on the third case while the first was 
> based on the first two. I hope that explains the contradiction.

I hope that too, but I still don't understand how this fails in the int 
case.  libstdc++ sources are simply too complicated to find out what's 
going on there when cin.clear() is called, given a few minutes of free 
time I had, and given that I have never tried to port libstdc++.

In particular, they seem to have an entire private emulation of the stdio 
libc functions as part of libstdc++, at least as an option.  I hope to 
God this option is not used in the DJGPP port, because if it is, this 
stuff will never work right.

It would be certainly swell if someone who knows their ways in the 
libstdc++ sources could look into this problem and explain how come 
cin.clear() doesn't clear the EOF flag.

One thing I'm sure: clearerr() in libc.a is never called by cin.clear.

- Raw text -