Date: Thu, 22 Apr 1999 17:54:11 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Bug no. 277 In-Reply-To: <199904221237.MAA95510@out4.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.