Working with I/O

This is not very complicated; we provide an input buffer called input to store the characters from the input. We also specify the length of the buffer in inputlen. After displaying some welcome messages, we call the function reads, which accepts all the characters from the keyboard and returns them to the caller when the Enter key is pressed. The calling program then uses the function prints to display the characters that were entered. Figure 19-1 shows the output.

There are some issues, however! We reserved 10 bytes for the input buffer. What happens if the input is longer than 10 characters? Figure 19-2 shows our result.

The program accepted only ten characters and doesn’t know what to do with the surplus characters, so it throws them back to the operating system. The operating system tries to figure out and interpret the characters as CLI commands but cannot find corresponding commands. Errors!

That’s not nice, but it’s even worse than at first glance. This way of handling input can cause a security breach, where a hacker can break out of a program and gets access to the operating system!

Dealing with Overflows

We modified the prints function so that it first counts the number of characters to display; that is, it counts until it finds a 0 byte. When the length is determined, prints displays the string with a syscall.

The reads function waits for one input character and checks whether it is a new line. If it’s a new line, the character reading from the keyboard stops. Register r14 holds the count of the input characters. The function checks whether the number of characters is larger than inputlen; if not, the character is added to the buffer input. If inputlen is exceeded, the character is ignored, but the reading from the keyboard continues. We require the ASCII code of the character to be 97 or higher and 122 or lower. This will guarantee that only lowercase alphabetic characters are accepted. Note that we saved and restored the callee-saved registers; we used r12 in both functions, prints and reads. In this case, not saving the callee-saved register would not be a problem, but you can imagine that if one function calls another and that one calls yet another, problems could arise.

Figure 19-3 shows the output.

Debugging console input with SASM is complicated because we are providing input via a syscall. SASM provides its own functionality for I/O, but we didn’t want to use it because we wanted to show how assembly and machine language work without hiding the details. If you get stuck with debugging in SASM, go back to our good old friend GDB.

Summary