jb1742@almsa-1.arpa (03/30/87)
In the statement--
if (c == "\n" || c == "\0")
OR
if (c == '\n' || c == '\0')
execution translates to--
if ( == '\n' || == '\0' )
and the statement bombs out because there is
no test argument given.
The way I have found around this is to write the
statement as:
if (xc == x || xc == x)
upon execution this translates to
if (x == x || xc == x)
Hope this is what you were looking for.
nab1382@dsacng1.UUCP (Dick Hauser) (06/01/88)
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.
Most of the readers of this newletter will consider this request
elementary. I really would appreciate some help. There must a
standard programming practice which helps eliminate this type of
problem. Also, I requested the names of some beginner thru
intermediate level programming books describing the use of
pointers. I posted the article to "comp.sources.wanted", but
nobody replied.
Like I said earlier, I am learning via trial-and-error, so thanks
in advance for any information you forward to me.
Dick Hauser
dsacng1/dhauser
--
Dick Hauser PHONE: +1616-961-5312 AV: 932-5312
Defense Systems Automation Center, Battle Creek, Mi.
UUCP: {uunet!gould,cbosgd!osu-cis}!dsacg1!dsacng1dhauser
...eecae!dsacng1!dhauser brb@akgua.ATT.COM (Brian R. Bainter) (06/02/88)
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
karl@haddock.ISC.COM (Karl Heuer) (06/03/88)
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