3.15.4 Why val doesn’t solve the whole problem

Things that paranoid people might bear in mind are

• Not all accidental changes to an SCCS file will necessarily make the file invalid.
• Since the checksum of an SCCS file is of finite length, there is a finite (though small) chance that a random change will not be detected by the checksum
• If data is corrupted in the memory of a program, then the program will write the incorrect data out to the history file and set the checksum accordingly (in other words, an on-disk checksum only protects the data while it is on the disk).
• Even if val concludes that a history file is structurally valid, this does not mean that the file contains what you thought it did (for example, perhaps the file was corrupted by having another, valid, SCCS file copied over it, or perhaps it was overwritten by an old backup version).
• Consumer-grade hardware (for example commodity PCs) generally lacks error-correcting memory.

Things that an optimistic person might bear in mind are

• The chances of a random change simultaneously fooling the checksum and the checks that val does are very small indeed.
• Hardware failures rarely cause file corruption. The use of ECC memory substantially reduces your changes of having undetected data corruption.
• When CSSC operates on an SCCS file, most of the checks that val performs are done anyway (CSSC differs slightly in this respect from the traditional SCCS toolset).

The summary is that it is theoretically possible to fool the integrity checks performed by the SCCS file checksum and by val but the checksum isn’t fooled often and the chances of fooling both together are very small. The use of quality hardware reduces the chance of data corruption yet further.