You're showing an example of something that could be a security bug if someone wrote that code, but you are missing the plot when it comes to memory safety and its connection to security.
What makes memory safety so important is that in C/C++, a missing bounds check on `name` gives you access to the entire heap, not simply the other fields within that allocation. Attackers aren't using missing bounds checks to look for `is_admin` fields in the same object. They're looking for a pivot to full memory control, so they can plug in their RCE exploit chain. So, the only time that attackers are looking for an intra-object overflow is if they have something like `struct { char buf[100]; void* ptr; }`, since that does lead to a pivot to full memory control. Fil-C protects that; you can't use that overflow to corrupt `ptr`'s capability.
This is why memory safety tech like MIE, MTE, and Fil-C focus on allocation granularity. If I wanted to support subobject granularity, I could; it's not a huge change to the capability model. Fil-C's first two capability models (back in late 2023, early 2024) supported subobject granularity. I'm choosing not to support it now because I understand the security implications well enough to know that it's not worth the complexity.
Fil-C started out as a macOS project. Fil-C supports Windows and macOS today via APE. Requiring recompiliation of everything is a luxury I can choose to support on Linux that results in memory safety of the whole process. If you find Fil-C useful and understand compilers, you could probably get a variant working that has FFI and then expose Windows and Mac API to it. You'd get something with a weaker safety guarantee, but no weaker than what you get today from Rust or Java.
What makes memory safety so important is that in C/C++, a missing bounds check on `name` gives you access to the entire heap, not simply the other fields within that allocation. Attackers aren't using missing bounds checks to look for `is_admin` fields in the same object. They're looking for a pivot to full memory control, so they can plug in their RCE exploit chain. So, the only time that attackers are looking for an intra-object overflow is if they have something like `struct { char buf[100]; void* ptr; }`, since that does lead to a pivot to full memory control. Fil-C protects that; you can't use that overflow to corrupt `ptr`'s capability.
This is why memory safety tech like MIE, MTE, and Fil-C focus on allocation granularity. If I wanted to support subobject granularity, I could; it's not a huge change to the capability model. Fil-C's first two capability models (back in late 2023, early 2024) supported subobject granularity. I'm choosing not to support it now because I understand the security implications well enough to know that it's not worth the complexity.
Fil-C started out as a macOS project. Fil-C supports Windows and macOS today via APE. Requiring recompiliation of everything is a luxury I can choose to support on Linux that results in memory safety of the whole process. If you find Fil-C useful and understand compilers, you could probably get a variant working that has FFI and then expose Windows and Mac API to it. You'd get something with a weaker safety guarantee, but no weaker than what you get today from Rust or Java.