3 ms·
> How can users be assured that this type of issue won't occur again? By writing code defensively. Despite the other comments, it's possible. The key is to be
by goodpoint 5y ago
> How can users be assured that this type of issue won't occur again?
By writing code defensively. Despite the other comments, it's possible.
The key is to be redundant: for example, off-by-one errors are very common when accessing an set of indexed items by number.
Yet you can split the set (e.g. an array) in multiple ones to make it more unlikely that you pick the wrong item (e.g. picture vs users).
You can also "tag" the outgoing image with some attributes, e.g. the recipient and a sent/not-sent flag.
You can cross-check and stop if something is inconsistent. Many other things are possible e.g. to protect from RAM bit flips.
It's not a matter of language or tooling, it's a matter of mindset.
- eganist 5y ago> By writing code defensively. Despite the other comments, it's possible. I'm going to tack onto this and suggest that signal drastically slow down the pace of feature development. They don't have the same profit motivations other companies have. The messaging market, at least in its current state, is largely known. These both give Signal an advantage in that they can slow down and harden the product while baking security into their DevOps practices as a first class citizen. Tl;dr: signal needs to slow down.