On 3/23/26 9:13 AM, Marin Ivanov wrote:
> Hi David,
>
> Just as I replied before, here follow my thoughts on the topic.
>
> On Sun, 22 Mar 2026 14:33:45 +0100
> David Hoppenbrouwers <david@???> wrote:
>
>> Memory safety *is* a property of the language, especially if you need
>> the language to run on bare-metal without a runtime.
>
> Memory-safety is a property of the program, not the language. The
> language can be designed to help compilers make programs with that
> property.

Memory safety is a property of both the program and the language.
Program semantics depend on language semantics.

> It is obvious that there are memory-safe programs in C compiled with
> GCC or LLVM. Just as a rule, every compiled Rust program, can be
> disassembled and translated to C, therefore the compiler would likely
> produce a memory-safe C program
>> Using a restrictive language to gain some property is one way to do it.
> For instance, using non-Turing-complete language in BPF or using
> restrictive C-like language that you can prove a property in compiled
> program in eBPF.

There are indeed memory-safe C programs, but Rust provides a stronger
guarantee: *all* programs written in Safe Rust are guaranteed to be
memory-safe. C does not provide such a guarantee.

>>> You may want to check Fil-C[1], which is a memory-safe
>>> C and C++ compiler. It has overhead though.
>>
>> Unlike Rust, Fil-C requires recompiling every single library. It also
>> requires a runtime, making it unsuitable for bare-metal development.
> I did not argue about this. I mentioned that there is an overhead. My
> argument is about calling a language "safe".
>
>> And from what I heard, it has a race condition in its capability
>> model which will _not_ be addressed because it would add even more
>> overhead.
>> https://gist.github.com/unixpickle/4eaae977d79c3b9eeda45d5baf52859f
> Therefore, if that problem is addressed, then the *compiler*, would produce
> even more memory-safe programs than the current C/C++ compiler or the
> Rust compiler with "pointer-twiddling unsafe Rust"[1].

As I already said, this problem will not be addressed as it cannot be
addressed without either a significant performance hit or doubling the
size of pointers.

Fil-C implements capabilities by using a "mirror" region for all
allocations. This is to keep pointers 8 bytes in size while also
avoiding a double indirection. This has two consequences:

1. You need ~2x the memory for every allocation (including the stack,
which AFAIK is implemented as a linked list of on-heap segments).

2. It is impossible to atomically read/write the pointer and the
capability in a "lock-free" manner, as there are no instructions on
x86-64 (or any mainstream architecture I'm aware of) to do that.

A consequence of 2. is that the only way to avoid tearing is by using a
lock. This will have a massive performance impact and Filip has already
stated he will not implement that (while downplaying the issue).

The easiest fix is to store the capability next to the pointer, which
allows the use of 16-byte atomic operations, similar to CHERI or Rust's
"fat pointers". Last I heard Filip is unwilling to do this.

And FWIW, Fil-C bypasses the need for "unsafe" by implementing the
entire syscall layer by himself (for Linux only). It is also why every
library needs to be recompiled: the only way to avoid recompilation
would be to add the equivalent of Java's JNI or Rust's unsafe.

>
> Kind regards,
> Marin
>
> References:
> ---
> 1. https://graydon2.dreamwidth.org/320265.html

David