That's a risk, yes. For our use case, there is very strict error checking/firmware signature verification on every process involving the flash, so the corruption case is always handled gracefully, leading to a full erase anyway.
Hey! Author here :) This is a very good question, and you're right that I should've expanded on my rationale as this is not standard practice at all.
There are some particularities of the data we're writing that make this case more common than usual, and in any case the time spent in the bit masking routine is negligible compared to the flash erase time, so it works out well (keep in mind that the `all()` consumer will short-circuit as soon as two bits differ, so in the general case it's cheap, and in the erased case it isn't too different from verifying every byte is 0xFF). We're also really, really strongly optimizing for flash life above speed, as this code is meant to run very rarely for FOTA upgrades.
For a general purpose storage flash driver, I'd definitely erase every sector.
This is exactly what I meant. Thanks Steve for the clear explanation!
In the next part of the article I'll hopefully explore some drawbacks of choosing generics all the way down. Either driver would've likely perform a little better if developed fully independently, but by a smaller margin that I would've expected.
Hey! You just made my day. James Mickens (that article in particular) was a huge inspiration, especially the part about crying blood. May have been a bit too dramatic...