[AlotOfReading]

There's plenty of reasons to prefer Rust to a memory-safe C. For example, I work on safety-critical code. That means that I have to review and affirm "This code implements my design". Making C memory-safe doesn't make the semantics of all UB defined or appropriate.

Safe rust doesn't have UB, and validating unsafe rust isn't meaningfully different than doing it for C++, except that it's limited to tiny leaf functions with well-defined interfaces where a code reviewer can challenge you.

[pizlonator]

> Making C memory-safe doesn't make the semantics of all UB defined or appropriate.

Fil-C largely gets rid of UB.

There are exceptions left but they’re all fixable.

The only reasons why C has UB are:

- lack of memory safety (Fil-C fixes this)

- policy (Fil-C mostly fixes this but there are still a small number of remaining issues, which I intend to fix).

Fil-C is super comprehensive in how it fixes C. I bet it’s more comprehensive than you’d expect.

The reason not to use Fil-C in safety critical systems is that some operations have varying cost and there’s a GC. The GC is concurrent so you might be able to make it suitable for safety critical hard realtime stuff; it would just be a lot of work and probably not worth it. Rust is better than Fil-C for hard real time stuff for that reason.

[AlotOfReading]

It's on my free-time backlog to spend more time with Fil-C, so I'm not disagreeing from lack of interest.

Most of annex-J is unrelated to memory safety. No, C has explicit UB because there wasn't a defined behavior that made sense to codify in the standards process. Signed overflow, invalid printf specifiers, and order of evaluation for example. I assume Fil-C doesn't fix things like uninitialized memory or division by zero either.

Wasn't really getting into the GC because that's "just" an engineering issue, rather than a structural issue with the approach.

It'd be great to not only terminate on detecting these issues as Fil-C does, but prevent them from happening entirely.

[pizlonator]

Fil-C absolutely does fix uninitialized memory.

It’s on my list to solve division. It’s easy to do and also not super important for the security angle that I’m addressing. But with doing precisely to provide clarity to these kinds of discussions.

I’ve mostly tackled signed overflow. I’ve fixed all the cases where signed overflow would let you bypass Fil-C’s own bounds checks. It’s not hard to fix the remaining cases.

In short: any remaining UB in Fil-C is just a bug to be fixed rather than a policy decision.

The reason why C has UB today is policy and memory safety.

Its a goal of Fil-C to address memory safety violations by panicking because:

- That’s the most secure outcome.

- That’s the most frantically compatible with existing C/C++ code, allowing me to do things like Pizlix (memory safety Linux userland)

[junon]

How does Fil-C "fix" uninitialized memory?

[tialaramex]

I assume under the same "memory safety" rationale it just zeroes the RAM. That's "safe" and compatible with C.

In a good language this mistake is caught at compile time, like in Rust, the compiler says "Hey, I don't see how this variable is initialized before use" and you slap your forehead and fix it. But zeroing everything is technically safe.

For the Casey "hand made" Muratori type zeroing might even seem like a better idea. It's cheap, it means now your code compiles and executes, who cares about correctness?

[junon]

I guess I don't see how making inherently incorrect C code "safe" by sanitizing something it shouldn't be doing anyway is actually improving the C code.

[pizlonator]

By initializing it to zero.