aborting an INT 21h,Ah with CTRL+C sometimes breaks the history buffer

[mateuszviste]

SvarCOM relies on the INT 21h,Ah service to obtain user input. I noticed that if I interrupt SvarCOM with CTRL+C, then this happens:

The message is misleading because I had implemented it to detect stack overflow situations, and this is not exactly what happens here. Whenever SvarCOM starts, it checks the sanity of its history buffer: it should start with 128 ("max. allowed input length"), the string should be terminated with a CR byte and followed by a 0xCAFE signature (appended by SvarCOM). If these conditions aren't met, then SvarCOM assumes a stack overflow that has overwritten the buffer and clears the buffer.

I added some debug code so SvarCOM outputs a hex dump of the history buffer. On it, we see that the history buffer is usually set to a length of zero by the kernel (second byte) and this, I think, fine. But there are also some rare cases when the length is not reset (on the screeshot below, the last example has length = 1), while the buffer is not properly terminated. This might cause issues with non-defensive software.

I am attaching the SvarCOM debug version here:
svarcom_history_debug.zip

[mateuszviste]

another side effect of this bug is that some cases (that are not detected by SvarCOM) lead to this:

ie. I typed the command "dd", then followed with "xx" but instead of pressing RETURN I aborted it with CTRL+C, then typed a single "s" letter, aborted with CTRL+C again, and then recalled the history using the right arrow key: it showed the phrase "sx" - a command that I actually never entered.

In a word, I think that the kernel should either:

1. take care of resetting the input buffer when being aborted with CTRL+C (maybe with a trailing \r)
2. not change the buffer until the user presses RETURN (it's what FreeDOS do, but it is likely an expesive option)
3. update the length at every key press, so in case it is aborted the history buffer will at least contain the last string typed