From owner-freebsd-questions Sun Dec 15 04:43:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA23855 for questions-outgoing; Sun, 15 Dec 1996 04:43:22 -0800 (PST) Received: from murkwood.gaffaneys.com (dialup14.gaffaneys.com [134.129.252.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA23831; Sun, 15 Dec 1996 04:43:15 -0800 (PST) Received: (from zach@localhost) by murkwood.gaffaneys.com (8.8.2/8.7.3) id GAA04600; Sun, 15 Dec 1996 06:44:07 -0600 (CST) To: jau@iki.fi Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: funny unstable behaviour in the stdio library... References: <199612151117.NAA24559@jau.thunderbolt.fi> Mime-Version: 1.0 (generated by tm-edit 7.89) Content-Type: text/plain; charset=US-ASCII From: Zach Heilig Date: 15 Dec 1996 06:44:06 -0600 In-Reply-To: jau@iki.fi's message of Sun, 15 Dec 1996 13:17:48 +0200 (EET) Message-ID: <87n2vg3rl5.fsf@murkwood.gaffaneys.com> Lines: 59 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk jau@iki.fi (Jukka Ukkonen) writes: ... > register char ch; ^^^^ you should really read into 'int's so when the various input functions return EOF, that value is distinguishable from all valid (unsigned) character values. If you _always_ use feof() correctly, this might not be an issue... > for (ch = fgetc (stdin); ! feof (stdin); ch = fgetc (stdin)) { ... > fseek (stdin, 0, SEEK_CUR); ^^^^^ fseek() on stdin is almost always a mistake. ... > When everything works as expected one would expect it produce > something like this... > input: XYZ > output: ch = 58 X > output: ch = 59 Y > output: ch = 5a Z Why this? You presumably have to type some character to send the line to the program for processing... Where is that character in the above output? > What I get without the additional call to fseek() is... fseek() on stdin when stdin is attached to a tty has no meaning. I only got the single line: ch = 58 X with the fseek() compiled in. (FreeBSD 2.2-ALPHA) > input: XYZ meaning you most likely typed: XYZ > output: ch = 58 X > output: ch = 59 Y > output: ch = 5a Z > output: ch = a Ahah! you did type a linefeed to send the line to your program. Of course your program will also read the linefeed and print it out. You did notice the extra blank line after the 'ch = a' line, right? :-) > Anyhow one does not (And should not have to!!) expect the stdin > change when calling one of the printf functions on the stdout > stream, if the input stream does not change also when using > the fputc() family of functions. The same weird behaviour seems > to be present at least on FreeBSD versions from 2.1.0-RELEASE > to 2.2-960501-SNAP. Does anyone have good ideas about why is > this as it is, and what could be done about it if anything? This is a pilot error, not a compiler (or library) bug.