Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?
From experience, actual (permanent) bricking is pretty unlikely. Generally, you'd have to do something that writes to flash or maybe does something bad with MMIO. Of course, there are no guarantees, but in practice a lot of people have shot DNG on ports with the raw buffers not correct, which reverses the entire contents of the buffer. As far as we know, no one in the history of CHDK has bricked a camera this way.
So I personally wouldn't worry too much about writing about 0xDEADBEEF to the entire buffer(s) and then checking it later. You could even do the write from the raw hook, which should be as safe as shooting DNG. You are only worried if it changes later (although it's quite possible jpeg processing destroys part of the buffer, which would leave you with the false impression that some of it was unusable when it was).
But really, implementing exmem is easier.
By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?
Generally speaking, bigger is better. It's likely like that matching the underlying filesystem and SD card block sizes is also better, but I'm not aware of any rigorous experimental tests under CHDK. It would be interesting to have a test like this.
You can also test the peak bandwidth using something like
https://chdk.setepontos.com/index.php?topic=13089.msg132605#msg132605 and then compare what you are getting. If you are within 10% of that, it's probably not worth worrying about trying to optimize.
Actually, what value will I see for memory locations that don't exist?
IIRC, outside of areas that are mapped to other things (ROM, MMIO etc) or protected by the MPU, you tend to see contents of RAM, with the out of range address bits ignored. So if your camera has 32 megs of RAM, the contents will appear to repeat after 32 megs.
