Changing the checksum VFS
I have a client who is working on safety-critical software, where it is much preferred for the software to crash than to accidentally use the wrong number. I've taken a look at the checksum VFS:
However, the software has existing standards for checksumming and the 8-bit method used by that specific code isn't quite what they want. Ideally, more bits and a different, specific, algorithm.
The source code to the VFS seems pretty clear. We have access to good programmers familiar with the SQLite API, and they already compile from SQLite source, and the SQLite CLI, using their preferred development platform.
Would that VFS be a good place to start in implementing a different checksum method ? Are there any gotchas not made plain by the source code ? The first changes would probably be
int n = 16 and
.filectrl reserve_bytes 16 in appropriate places.
(I'll be doing my best to get any changes made available to the SQLite dev team, or available under one of the standard Open licenses. Unfortunately, due to the way the project is funded, this is not easy and inevitable.)
cksumvfs.c uses an 8-byte checksum, 64-bits, not an 8-bit checksum. Is that a typo in your original post, or a fundamental misunderstanding?
If you are after a 16-byte, 128-bit checksum, I think the cksumvfs.c source file would be a good starting point. Just swap out the "cksmCompute()" function with whatever 128-bit checksum algorithm you have in mind, and make a few other strategic "8"-to-"16" edits, and you should be good to go.
Thanks for the reply. 8 bytes is indeed enough for our purposes. I should have paid more attention when quickly scanning the source code. Swapping out
cksmCompute() appears to be all we need to do.
Annoyingly, the checksum routine we substitute isn't as good as yours, and it will reduce the statistical rigour of checksumming. But it is already documented as part of the project, and the C code used has already passed the certification process, which requires a lot of effort and time. So for this project it's a better choice.
I appreciate your help and I expect SQLite will be saving lives as a result. SQLite will be appropriately credited, and no responsibility will be assigned to the SQLite team.