4 ms·

There's a very good reason such a thing doesn't exist: any C compiler that worked like that would break the vast majority of C programs. Fundamentally, memory

There's a very good reason such a thing doesn't exist: any C compiler that worked like that would break the vast majority of C programs. Fundamentally, memory safety requires that you keep track of not just where a pointer currently points to, but where a pointer could validly point to. But, as applied in practice, the C ABI requires that pointers be integers of where it currently points to; making pointers also include range information (aka "fat" pointers) is possible, but requires rewriting almost any software you care about--it's the kind of change that's about as fundamental to C programs as assuming 2's complement arithmetic. The way tools like ASAN and Valgrind work is by instead keeping track of where any pointer could point to (via shadow maps, basically a bit per memory location saying if you can read/write that location), and then padding every allocation with sufficient space that an innocuous read overflow (especially one-past-the-end) is likely to hit the padding. Their guarantees are at best probabilistic, not anything you would want to rely on for security.

_0w8t 5y ago
Given that one can compile C to Wasm it is simply not true that it would break C code. Wasm implements pointers as offset into an array and then checks for out-of-bounds access. LLVM should be able to do that directly.
jrtc27 5y ago
Most C and C++ code is perfectly happy with fat pointers provided you take care in how you implement them, especially around (u)intptr_t. For CHERI we see a very tiny % of LoC that need changing; e.g. http://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf http://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-ch... documents a recent case study in porting a KDE desktop stack (X11 itself, Qt, other standard graphical desktop libraries, Plasma, Dolphin, Okular) and across the 6 million LoC only 0.026% needed changing. So, if you pick your fat pointer implementation poorly, then yes, you run up against both the standard and de-facto C, but if you take care then the vast majority of C code just works, and we're (uniquely?) positioned to be able to prove that by having a FreeBSD-based kernel and userspace, and graphical desktop stack (plus an adaptation of WebKit's JSC JIT) all built with a compiler that maps C pointers to capabilities that enforce fine-grained bounds.

_0w8t 5y ago

Given that one can compile C to Wasm it is simply not true that it would break C code. Wasm implements pointers as offset into an array and then checks for out-of-bounds access. LLVM should be able to do that directly.

jrtc27 5y ago

Most C and C++ code is perfectly happy with fat pointers provided you take care in how you implement them, especially around (u)intptr_t. For CHERI we see a very tiny % of LoC that need changing; e.g. http://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf http://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-ch... documents a recent case study in porting a KDE desktop stack (X11 itself, Qt, other standard graphical desktop libraries, Plasma, Dolphin, Okular) and across the 6 million LoC only 0.026% needed changing. So, if you pick your fat pointer implementation poorly, then yes, you run up against both the standard and de-facto C, but if you take care then the vast majority of C code just works, and we're (uniquely?) positioned to be able to prove that by having a FreeBSD-based kernel and userspace, and graphical desktop stack (plus an adaptation of WebKit's JSC JIT) all built with a compiler that maps C pointers to capabilities that enforce fine-grained bounds.