| | |
Clearing input stream
![]() |
Hi,
Someone told me to use this code to clear the input buffer..
But I fail to understand how it actually works.
For example, there are two newline characters in the buffer
Now getchar() grabs the first '\n', stores it in ch and compares ch with '\n' and EOF to see if the condition is true or not. Like this
So the condition is false, the loop will terminate. What about the second '\n'? Its still in the buffer !!! So is this code for clearing only 1 newline character from the buffer?
Someone told me to use this code to clear the input buffer..
C Syntax (Toggle Plain Text)
while((ch=getchar())!='\n' && ch !=EOF);
But I fail to understand how it actually works.
For example, there are two newline characters in the buffer
•
•
•
•
This is my buffer
\n \n
C Syntax (Toggle Plain Text)
(ch != '\n' && ch !=EOF) This gives (false && true) = false.
So the condition is false, the loop will terminate. What about the second '\n'? Its still in the buffer !!! So is this code for clearing only 1 newline character from the buffer?
All suspects are guilty until proven innocent, other wise, they wouldn't be suspects would they?
>What about the second '\n'?
It doesn't exist. That loop is designed for line-oriented interactive input from stdin. Because a newline is expected to terminate the buffering mechanism for your shell, there will only ever be one newline, and that newline will mark the end of the buffer. As such, the loop isn't a complete solution, but it's close enough if you use it for the purpose it was designed.
It doesn't exist. That loop is designed for line-oriented interactive input from stdin. Because a newline is expected to terminate the buffering mechanism for your shell, there will only ever be one newline, and that newline will mark the end of the buffer. As such, the loop isn't a complete solution, but it's close enough if you use it for the purpose it was designed.
I'm here to prove you wrong.
>How about an EOF following the \n?
That won't happen either. When you press the Enter key, the buffered characters in the shell are sent to your program for processing. That means every character up to and including the newline represent a single input transaction. You can't add characters to the transaction after sending it in for processing, so the EOF signal would be a part of the next transaction, making it irrelevant to this transaction.
The two situations you've described won't happen in line-oriented interactive input, but they can happen if stdin is redirected to a file, which is why this isn't a complete solution. However, the "newline stuck in the input stream" problem doesn't seem to be as much of an issue when dealing with files. It's usually a matter of people not fully understanding how streams work and muxing up interactive input.
>What is the possible complete solution?
There isn't one. When more than one interpretation for a stream of characters exists, it's impossible to have a complete solution to any problem because for at least one interpretation, it won't even be a problem.
That won't happen either. When you press the Enter key, the buffered characters in the shell are sent to your program for processing. That means every character up to and including the newline represent a single input transaction. You can't add characters to the transaction after sending it in for processing, so the EOF signal would be a part of the next transaction, making it irrelevant to this transaction.
The two situations you've described won't happen in line-oriented interactive input, but they can happen if stdin is redirected to a file, which is why this isn't a complete solution. However, the "newline stuck in the input stream" problem doesn't seem to be as much of an issue when dealing with files. It's usually a matter of people not fully understanding how streams work and muxing up interactive input.
>What is the possible complete solution?
There isn't one. When more than one interpretation for a stream of characters exists, it's impossible to have a complete solution to any problem because for at least one interpretation, it won't even be a problem.
I'm here to prove you wrong.
![]() |
Similar Threads
- How do I flush the input stream? (C++)
- clear stream (C)
- overloaded input stream help (C++)
- Clearing input (C)
Other Threads in the C Forum
- Previous Thread: How do i use EOF in my program ??
- Next Thread: Doubly Linked List Doesnt Work
| Thread Tools | Search this Thread |
#include * adobe ansi array asterisks binarysearch centimeter changingto char character cm convert copyimagefile cprogramme creafecopyofanytypeoffileinc database dynamic execv feet fgets file floatingpointvalidation fork function getlogicaldrivestrin givemetehcodez global grade gtkwinlinux hacking histogram ide inches include incrementoperators infiniteloop input interest intmain() iso kernel keyboard kilometer license linked linkedlist linux list locate looping lowest matrix meter microsoft mqqueue number oddnumber opendocumentformat opensource openwebfoundation owf pattern pdf performance pointer posix power probleminc process program programming radix recursion recv recvblocked research reversing segmentationfault sequential single socket socketprograming socketprogramming standard strchr string suggestions systemcall test threads turboc unix urboc user variable voidmain() wab whythiscodecausesegmentationfault windowsapi






