[pizlonator]

Sure all of those are escape hatches that work against any memory safety tech.

Point is, Fil-C goes further than any other memory safety tech in terms of what it guards

[modeless]

Fully agreed. At some point you have to draw a line and say that the rest is the responsibility of the kernel and hardware and user, and I think Fil-C drew that line in the right place.

[josephg]

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

[pizlonator]

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does.

So Fil-C is safer than those

[josephg]

The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs.

> Fil-C is safer than those

Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work.

But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.

[Splizard]

Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.

[pizlonator]

Yeah what I said is true of TS and C#, but not of Go.

Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.

[quotemstr]

Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved.

Fil-C's safety guarantees therefore fail to apply in this situation.

[pizlonator]

Nonsense.

In a race, you at worst access an object you could have loaded from whatever field you were racing on.

In Go, you can bypass all protections and corrupt all of memory if you race on structs (I think).

[ncruces]

Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.

[quotemstr]

If we strip away the semantic maneuvering, your argument becomes this: Rust is unsafe because it lets people who aren't you, Pizlo, write unsafe code. Safety means trusting only you with machine code.

Anyone could do the same with a Rust lint rule if he wanted. He wouldn't, because this policy is not the way to secure software.