Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Help with strings
Message-ID: <4390@haddock.ISC.COM>
Date: 3 Jun 88 04:50:01 GMT
References: <347@dsacng1.UUCP> <1793@akgua.ATT.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 25

In article <1793@akgua.ATT.COM> brb@akgua.ATT.COM (Brian R. Bainter) writes:
>A quirk which I found by trial and error is that scanf has a problem.
>This statement may receive some flames, but what the heck, it's true.

Well, sort of.  The "problem" is that scanf does what you tell it instead of
what you want.

>If you call scanf and then call getchar, getc, gets, etc. after, the call to
>the get will not return any thing. This is because of a bug in scanf which
>leaves a newline in the buffer from the call that was made to it.

It is not a bug: scanf() is intended for free-format input, fgets() is for
line-oriented input.

>I find this most annoying myself and I refuse to use scanf because of it.

If line-oriented (e.g. prompted) input is what you're after, then refusing to
use scanf is indeed the appropriate action.

>If this is the case, you can ... put a getchar call just after the scanf

If you want to ignore all input up to and including the newline, you can add
"%*[^\n]%*c" to the end of the scanf format.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint