Skip site navigation (1)Skip section navigation (2)
Date:      15 Dec 1996 06:44:06 -0600
From:      Zach Heilig <zach@blizzard.gaffaneys.com>
To:        jau@iki.fi
Cc:        hackers@freebsd.org, questions@freebsd.org
Subject:   Re: funny unstable behaviour in the stdio library...
Message-ID:  <87n2vg3rl5.fsf@murkwood.gaffaneys.com>
In-Reply-To: jau@iki.fi's message of Sun, 15 Dec 1996 13:17:48 %2B0200 (EET)
References:  <199612151117.NAA24559@jau.thunderbolt.fi>

next in thread | previous in thread | raw e-mail | index | archive | help
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<return>

> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87n2vg3rl5.fsf>