Lit. Buffer overruns 1717

(paul c) writes:

Thirty-one digits is enough for just about anything anyway. But one day I discovered a quirk in the Univac 9300 (their answer to the 360-20). When one of my programs executed a Multiply Packed (MP) instruction, data beyond the end of the multiplicand was being clobbered for no apparent reason. I single-stepped the processor, displaying memory before and after each instruction. It was definitely happening when the machine executed the MP instruction.

Then the awful truth hit me. The hardware was ignoring the length field in the instruction, and just scanning through the multiplicand until it found a byte containing a valid sign (hex C, D, or F in the low-order nybble). On the run in question, I had packed a blank field (0x40 - this is EBCDIC, remember), so the low-order nybble of the multiplicand was not C, D, or F, but 4 - which the machine took as a valid digit so it kept on scanning memory. Resorting to the standard programming trick of ORing a hex 0C into the low-order byte of the multiplicand made the program run properly regardless of input data.

Later I exploited this quirk in a program that calculated factorials. It cleared a 25K area in memory to binary zero, stuffed a packed decimal 1 (0x1c) in the last byte, and proceeded to multiply this area by a convential 3-byte packed field that was incremented each time through the loop. A single instruction worked with an operand that was 50,000 digits long! Such a multiplication took nearly a second to execute; single-stepping the processor gave an interesting display on the lights.

-- I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!