3 ms·
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise" The point with being able to do this though
by codetrotter 7y ago
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"
The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way.
The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.
- mikepurvis 7y agoAnd in the specific case of cryptographically secure code, you may well need to be paying attention to extremely low level details like the number of instructions being executed on different branches, the states of various buffers and caches, etc. It may well be that it doesn't make sense to expose control over these things to the high level layer where it's irrelevant 99% of the time.