3 ms·
LOL. It's a fact. It was discovered by a fellow student.
by WalterBright 7mo ago
LOL. It's a fact. It was discovered by a fellow student.
- ButlerianJihad 7mo ago[flagged]
- WalterBright 7mo ago> It’s quite impossible. Do you know all about 1970s operating systems? Why do you find it hard to believe that a loop deleting backwards from the buffer wouldn't, say, zero out the stack frame and then a function return crashes it? > Was it identified as a bug or vulnerability? What difference does that make? It crashed the -10. It was reported. > What OS, even? The TOPS-10 operating system, or its predecessor. I don't recall just when TOPS-10 came out. It was 50 years ago.
- ButlerianJihad 7mo ago[flagged]
- rcxdude 7mo agoIt's really not a very hard thing to imagine. The contents of the terminal screen were likely just a simple buffer in memory with the cursor position being a pointer into that memory. One missing bounds check and backspace starts messing with OS datastructures.
- shakna 7mo agoI'd call it even likely, with most of the flat memory OSs of the past. We are talking 50 years ago. C64 had a flat memory map, where the input came as the first address in range 0 to DFFF. What came after that? The kernel. So if you wrote too much data into the input address space, and the overflow wasn't caught, you'd overwrite the OS there, too. And writing into the IO table was common, because it was faster to access.
- ButlerianJihad 7mo agoBy using a backspace key‽
- shakna 7mo agoIn some systems, backspace was not buffered. It shifted the last offset position of the memory position to be stored for the next character. Backspace may just be pc--, and every other character is just a poke. This is pre-ASCII. There was no standardisation of how you might expect input to work. For example, there is no backspace character in unshifted PETSCII.