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