Skip to content
Advertisement

Clear input buffer Assembly x86 (NASM)

Edit: This is similar to this: Reset a string variable to print multitple user inputs in a loop (NASM Assembly). But it is not the same issue.

From the other post, I was able to prevent additional characters from being printed. However, I still cannot prevent those additional characters from being read when the program goes back to the point in which it asks the user for input.


I’m creating a program that asks an user for input, and then prints it. Afterwards, it asks the user to enter ‘y’ if they want to print another text, or press anything else to close the program.

My issue is that if the user enters more characters than expected, those extra characters don’t go away, and when the program goes back to ask the user for input, there’s no chance to enter input because the program takes the remaining characters from the last time it received input.

For example:

The user is asked to enter text to print, and they enter: “Heyyyyyyyyyyyyyyyyyyyyyyyyyyyyy”

Leftover is “yyy”

At this point, the program should ask the user to enter ‘y’ to repeat the process, or anything else to close the program.

Output:

  • Heyyyyyyyyyyyyyyyyyyyyyyyyyy

  • Wanna try again? If yes, enter y. If not, enter anything else to close the program

  • Enter your text:

Output: yy

  • Wanna try again? If yes, enter y. If not, enter anything else to close the program.

And only now it asks for user input again

Since “yyy” is still in buffer, the user doesn’t get a chance to actually enter input in this case.

What can I do to fix this issue? I’ve just started to learn about this recently, so I’d appreciate any help.

Thanks.

This is what I’ve done

JavaScript

Advertisement

Answer

The simple way to clear stdin is to check if the 2nd char in choice is the 'n' (0xa). If it isn’t, then characters remain in stdin unread. You already know how to read from stdin, so in that case, just read stdin until the 'n' is read1, e.g.

JavaScript

Beyond that, you should determine your prompt lengths when you declare them, e.g.

JavaScript

That way you do not have to hardcode lengths in case you change your prompts, e.g.

JavaScript

If you put it altogether, you can do:

JavaScript

Example Use/Output

JavaScript

Now even a cat stepping on the keyboard at your (y/n)? prompt won’t cause problems. There are probably more elegant ways to handle this that would be more efficient that repetitive reads, with syscall, but this will handle the issue.


Additional Considerations And Error-Checks

As mentioned above, the simplistic reading and checking of a character-at-a-time isn’t a very efficient approach, though it is conceptually the easiest extension without making other changes. @PeterCordes makes a number of good points in the comments below related to approaches that are more efficient and more importantly about error conditions that can arise that should be protected against as well.

For starters when you are looking for information on the individual system call use, Anatomy of a system call, part 1 provides a bit of background on approaching their use supplemented by the Linux manual page, for read man 2 read for details on the parameter types and return type and values.

The original solution above does not address what happens if the user generates a manual end-of-file by pressing Ctrl+d or if a read error actually occurs. It simply addressed the user-input and emptying stdin question asked. With any user-input, before you use the value, you must validate that the input succeeded by checking the return. (not just for the yes/no input, but all inputs). For purposes here, you can consider zero input (manual end-of-file) or a negative return (read error) as a failed input.

To check whether you have at least one valid character of input, you can simply check the return (read returns the number of characters read, sys_read placing that value in rax after the syscall). A zero or negative value indicating no input was received. A check could be:

JavaScript

You can write a short diagnostic to the user and then handle the error as wanted, this example simply exits after outputting a diagnostic, e.g.

JavaScript

Now moving on to a more efficient manner for emptying stdin. The biggest hindrance indicate in the original answer was the repeated system calls to sys_read to read one character at a time reusing your 2-byte choice buffer. The obvious solution is to make choice bigger, or just use stack space to read more characters each time. (you can look at the comments for a couple of approaches) Here, for example we will increase choice to 128-bytes which in the case of the anticipate "yn" input will only make use of two of those bytes, but in the case of an excessively long input will read 128-bytes at a time until the 'n' is found. For setup you have:

JavaScript

Now after you ask for (y/n)? your read would be:

JavaScript

Now there are two conditions to check. First, compare the number of characters read with your buffer size choicesz and if the number of characters read is less than choicesz, no characters remain unread in stdin. Second, if the return equals the buffer size, you may or may not have characters remaining in stdin. You need to check the last character in the buffer to see if it is the 'n' to indicate whether you have read all the input. If the last character is other than the 'n' characters remain unread (unless the user just happened to generate a manual end-of-file at the 128th character) You can check as:

JavaScript

(note: as noted above, there is a further case to cover, not covered here, such as where the user enters valid input, but then generates a manual end-of-file instead of just pressing Enter after the 128th character (or a multiple of 128). There you can’t just look for a 'n' it doesn’t exist, and if there are no more chacters and call sys_read again, it will block wating on input. Conceivably you will need to use a non-blocking read and putback of a single character to break that ambiguity — that is left to you)

A comlete example with the improvements would be:

JavaScript

There are surely more efficient ways to optimize this, but for purposes of discussion of “How do I empty stdin?”, this second approach with the buffer size used alieviates the repetitive calls to sys_read to read one character at-a-time is a good step forward. “How do it completely optimize the check?” is a whole separate question.

Let me know if you have further questions.

Footnotes:

1. In this circumstance where the user is typing input, the user generates a 'n' by pressing Enter, allowing you to check for the 'n' as the final character in emptying stdin. The user can also generate a manual end-of-file by pressing Ctrl+d so the 'n' isn’t guaranteed. There are many still other ways stdin can be filled, such as redirecting a file as input where there should be a ending 'n' to be POSIX compliant, there too that isn’t a guarantee.

Advertisement