35s program checksums

[r. pienne]

The mechanism where insertion/deletion of lines causes following lines to get renumbered, references to those lines updated, and checksums changed accordingly, is certainly not a bug; it's a desired feature. Assuming it works properly.

The bug-list says that checksums are "meaningless", without going into detail. But checksums are supposed to be meaningless; they're a one-way hash of the contents of the program (OK, the inter-label code) designed simply to indicate (yes or no) whether the instructions were entered correctly or not. As long as the checksum for a given block of code (allowing for automatic changes to GTO/XEQ lines) is always the same, then it's working.

I imagine it would not be a simple matter to reverse-engineer the checksum algorithm, so that we could predict the checksum of a program.

I haven't yet seen any evidence that the checksum mechanism is buggy.

R.