I meant tampering via a side channel attack (e.g. forcing a bit flip that ecc would protect). It doesn’t matter if your data types have referential integrity if a hacker could disable that protection.
What I am arguing against is saying a typesafe language obviates the need for ecc memory.
> What I am arguing against is saying a typesafe language obviates the need for ecc memory.
Which isn't what anyone said: I claimed you can do ECC in software and that type systems assist with that by making a clean interface and verifying the full implementation. (Since ECC is really just a lift of normal functions.)
There's little difference between using 9 bits in hardware and 9 bits in software, except that you need to cleanly load your ECC code onto CPU cache and you're using CPU instructions per byte loaded. The reason we do ECC in hardware is efficiency on an operation we're doing on literally every byte.
Lots of systems, eg harddrives, use ECC in their actual formats too, because you can do more complex ECC at the software level and not merely the extra bit. Sometimes, this software ECC is more efficient than hardware based ECC would be, because we're okay with less than 12.5% redundancy as long as we can still correct the errors we expect to find.
What I am arguing against is saying a typesafe language obviates the need for ecc memory.