This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Analysis of libstdc++/2071 test case
- To: schmid at snake dot iap dot physik dot tu-darmstadt dot de
- Subject: Re: Analysis of libstdc++/2071 test case
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Wed, 9 May 2001 15:19:55 -0500 (CDT)
- CC: libstdc++ at gcc dot gnu dot org
- References: <Pine.LNX.4.21.0105091830040.7217-100000@snake.iap.physik.tu-darmstadt.de>
- Reply-to: rittle at rsch dot comm dot mot dot com
Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de> writes:
> First of all, I like to thank you for your excellent analysis of the
> problem. I can confirm that reading from cin produces illegal seeks.
You are quite welcome.
> If I add some error checking to your second code, check the value of
> errno, and run the resulting program compiled by gcc version 3.1
> 20010508 (experimental) on i686-pc-linux-gnu (glibc 2.2).
[...]
> The output is as follows:
> ./a.out
> 1234
> Illegal seek
> 1 2 29
Yes, I had noticed that Linux also considers the fseek on stdin to be
illegal but it appears to not flush the input buffer as is done on BSD
and (guessing since I didn't look as closely and have no OS source
code) Solaris.
> I see no reason why the call to fseek is not dropped when reading from
> stdin.
Unfortunately, those fseeks appear to be in the code for a reason and
blinding dropping them may not be a good idea. I am learning the code
so I can develop a patch.
Regards,
Loren