Our results are extremely exciting: It appears that key elements of the stack
were adapted for memory-safe execution with little difficulty (0.026% LoC changed), and that
CHERI memory safety and CHERI software compartmentalization had a strong potential
mitigation impact (ranging from 40% of past vulnerabilities for KDE up to 100% in key
supporting libraries). We described a number of limitations to our study, and key directions
for ongoing research and development

In total we compiled more than 6 million source lines of code for CHERI C/C++ successfully with only a very few changes: 2071 LoC or 0.034%

var ptr: [*]u32 = ...;
ptr.address += 1;
ptr.permissions = .read_only;

This is apocalyptic for us. We, and our users would strongly prefer missing C++17 features than a Boost.Math dependency.

If LLVM moves forward with this, we will very likely patch it out.

export executable "hello";

#link("c")
extern {
    fn printf(__format: *const u8, ...) -> i32;
    fn exit(__status: i32) -> unreachable;
}

export fn _start() -> unreachable {
    printf("Hello, world!\n");
    exit(0);
}

const io = @import("std").io;

pub fn main() -> %void {
    %return io.stdout.printf("Hello, world!\n");
}

const std = @import("std");

pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write("Hello, world!\n");
}