Comment by fguerraz
21 hours ago
Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.
Thank you for mentioning this.
I wonder IFF Rust had an effects system that a Jasmin MIR transform (ie like SPIRV is for shaders) would be useful?
https://github.com/jasmin-lang/jasmin
Video codecs just don't need to do dynamic allocations because it's not relevant to the problem. There's still certainly plenty of opportunities for memory bugs because there's a lot of pointer math.
What in the world do you mean by “non-deterministic”?
C compilers, Rust compilers, and assemblers are all deterministic.
In cryptography, you want operations to run in constant time, even if it’s wasteful, otherwise an attacker could guess information about the key or plaintext by measuring execution times.
Modern compilers are extremely clever and will produce machine code that takes full advantage of modern CPU branch predictors, and reorder instructions to better take advantage of pipelining. This in itself will make the same code run at different speeds depending on the input data.
Then there is the whole issue of compiler version roulette. As a developer you have no idea which version of compilers your users and distros will use, and what new and wonderful optimisation they will bring.
I know that, but none of that makes the compiler output non-deterministic.
Determinism does not mean “easy to predict”, it just means “predictable”.
> C compilers, Rust compilers, and assemblers are all deterministic.
Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.