Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mtunx!akgua!brb From: brb@akgua.ATT.COM (Brian R. Bainter) Newsgroups: comp.lang.c Subject: Re: Help with strings Message-ID: <1793@akgua.ATT.COM> Date: 2 Jun 88 16:27:45 GMT References: <347@dsacng1.UUCP> Organization: AT&T Network Systems/Bell Labs, Atlanta GA Lines: 27 From article <347@dsacng1.UUCP>, by nab1382@dsacng1.UUCP (Dick Hauser): > I am requesting information about a problem I have encountered. > Standard input is being accessed using get(3). In some instances, > processing does halt and await input from STDIN. I read the > man documentation which says "The string is terminated by a newline > character, which is replaced by null character. Since I have not > entered any information via the keyboard, the input buffer must > contain information which is terminating the get before any > I have the opportunity to enter information. Processing ignores > the get I have issued. > > Dick Hauser > dsacng1/dhauser 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. 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. I find this most annoying myself and I refuse to use scanf because of it. If I were you I would check to see if a scanf call precedes your get call somewhere in your code. If this is the case, you can either replace the scanf with something a little more cooperative or put a getchar call just after the scanf call. If this is not the problem, good luck. Brian R. Bainter