4 ms·
We chose to start with temporal safety (use-after-free, uninitialised memroy etc) but are going to implement spacial safety (buffer overflows/underflows) soon (
by betz47 3y ago
We chose to start with temporal safety (use-after-free, uninitialised memroy etc) but are going to implement spacial safety (buffer overflows/underflows) soon (See roadmap https://xr0.dev/vision-roadmap https://xr0.dev/vision-roadmap).
Xr0 is not limited to memory-safety, its goal is to eliminate the possibility of writing C code that results in undefined behaviour. A good analogy can be drawn to how Typescript wraps Javascript and provides type safety. Think of Xr0 as a wrapper to C that guarantees you don't violate C's safety semantics.
- scns 3y ago> A good analogy can be drawn to how Typescript wraps Javascript and provides type safety. Like this idea a lot. Does that mean it could be used to convert C projects in a strangler pattern style?
- woodruffw 3y agoC doesn’t particularly strong safety guarantees of its own around type punning, which is logic bugs that aren’t themselves memory corruption so frequently result in exploitable vulnerabilities in C (and C++) codebases. How do you plan to handle things like that? (Other proposals that I’m aware of seek to forbid those parts of the language outright, or add some kind of runtime instrumentation like isoheaps. Neither of these is particularly palatable for pre-existing codebases with deep, undocumented language feature and ABI assumptions!)