The issue isn't whether it's possible to have parsers, but whether it's possible to have them be secure, and periodic CVEs "everywhere" suggest we don't

▲

cxr 3 hours ago | parent [-]

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 an hour ago | parent | next [-]

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

▲

duskwuff 2 hours ago | parent | prev [-]

> 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 an hour ago | parent [-]

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

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

	▲	rpadovani 21 minutes ago \| parent [-]
		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.