The issue isn't whether it's possible to have parsers, but whether it's possible...

cxr · 2026-09-22T04:00:06

Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations (so not GCC or Clang upstream), which CVEs specifically would have been ameliorated by a parser written in Rust instead of C?

eviks · 2026-09-22T05:29:43

Aside from the fact that it's not solved by using an alternative compiler, why would you put the core advantage aside?

cxr · 2026-09-22T12:33:56

What?

duskwuff · 2026-09-22T05:06:29

> Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations

I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).

hellcow · 2026-09-22T05:27:37

Behold: https://fil-c.org/

An important improvement over rust is that "Fil-C has no unsafe statement."

rpadovani · 2026-09-22T06:32:01

As everything, there are compromises and prices to pay.

In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.

So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.

GoblinSlayer · 2026-09-22T07:31:34

Rust is slower too, and git is IO bound anyway, and routinely calls bash.

insanitybit · 2026-09-22T13:53:55

Rust is not 1.5-4x slower at all. Git is not IO bound at all, it is not saturating your IO device, it just performs IO a lot.